From member at linkedin.com Sun May 4 01:04:34 2014 From: member at linkedin.com (=?UTF-8?Q?=E9=AB=98=E6=B0=B8=E4=BC=9F_via_LinkedIn?=) Date: Sun, 4 May 2014 01:04:34 +0000 (UTC) Subject: eris, please add me to your LinkedIn network Message-ID: <2101124602.3993462.1399165474702.JavaMail.app@ela4-app7996.prod> LinkedIn ------------ ??? requested to add you as a connection on LinkedIn: ------------------------------------------ I'd like to add you to my professional network on LinkedIn. Accept invitation from ??? http://www.linkedin.com/e/-9jv3q4-hurmzxqe-35/uUwiAqzf418olGWw58mjSTvkm1HgTG3IrG82TCkxhF79SC/blk/I692496090_13/0UcDpKqiRzolZKqiRybmRSrCBvrmRLoORIrmkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPclYMej0SejgOejp9bTkSjP9GhTsMbP0ScjoNdP8OcPARdz8Te34Re3kLrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=0Rka8MFW60QSc1 View profile of ??? http://www.linkedin.com/e/-9jv3q4-hurmzxqe-35/rso/331890621/z5ep/name/95734402_I692496090_13/?hs=false&tok=2X8HcVM1O0QSc1 ------------------------------------------ You are receiving Invitation emails. This email was intended for eris rachmatturisman. Learn why this is included: http://www.linkedin.com/e/-9jv3q4-hurmzxqe-35/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=2ssDSTdlm0QSc1 (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grantksupport at operamail.com Sun May 4 16:04:15 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 09:04:15 -0700 Subject: Upgrading v3 -> v4; vcl check fails @ req.backend . What have I missed? Message-ID: <1399219455.16859.113500961.3EFF42DE@webmail.messagingengine.com> Hi, I've upgraded from Varnish 3 -> 4, and am working on converting my VCL, following "Upgrading to Varnish 4" https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html After making changes as I've understood them, I thing I've gotten most right, but on config file check, I still get a fail, varnishd -C -f vcl.SITE.conf Message from VCC-compiler: Unknown variable 'req.backend' At: ('input' Line 94 Pos 81) if (req.url ~ "\.(css|css?.*|woff|eot|svg|ttf|otf)$") { set req.backend = css_SITE1; } --------------------------------------------------------------------------------###########------------------------- Running VCC-compiler failed, exit 1 VCL compilation failed I've likely missed/misunderstood a required change :-/ Here's the relevant snip from my config ... backend def_SITE1 { .port = "10100"; include "/usr/local/etc/varnish/backend_common.vcl"; } backend css_SITE1 { .port = "10101"; include "/usr/local/etc/varnish/backend_common.vcl"; } backend js_SITE1 { .port = "10102"; include "/usr/local/etc/varnish/backend_common.vcl"; } backend img_SITE1 { .port = "10103"; include "/usr/local/etc/varnish/backend_common.vcl"; } backend def_FALLBACK { .port = "9999"; include "/usr/local/etc/varnish/backend_common.vcl"; } sub hostname_normalize { if (req.http.host == "www.mydomain.net" ) { set req.http.host = "mydomain.net"; } sub backend_assign { if (req.http.host == "mydomain.net" ) { 94 if (req.url ~ "\.(css|css?.*|woff|eot|svg|ttf|otf)$") { set req.backend = css_SITE1; } elseif (req.url ~ "\.(js|js?.*)$" ) { set req.backend = js_SITE1; } elseif (req.url ~ "\.(jp(e?)g|gif|png|ti(f?)f)$" ) { set req.backend = img_SITE1; } else { set req.backend = def_SITE1; } } ... What's "req.backend" need to be changed to? Grant From dridi.boukelmoune at zenika.com Sun May 4 16:22:12 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Sun, 4 May 2014 18:22:12 +0200 Subject: Upgrading v3 -> v4; vcl check fails @ req.backend . What have I missed? In-Reply-To: <1399219455.16859.113500961.3EFF42DE@webmail.messagingengine.com> References: <1399219455.16859.113500961.3EFF42DE@webmail.messagingengine.com> Message-ID: On Sun, May 4, 2014 at 6:04 PM, wrote: > Hi, > > I've upgraded from Varnish 3 -> 4, and am working on converting my VCL, > following > > "Upgrading to Varnish 4" > https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html > > After making changes as I've understood them, I thing I've gotten most > right, but on config file check, I still get a fail, > > varnishd -C -f vcl.SITE.conf > Message from VCC-compiler: > Unknown variable 'req.backend' > At: ('input' Line 94 Pos 81) > if (req.url ~ > "\.(css|css?.*|woff|eot|svg|ttf|otf)$") { set > req.backend = css_SITE1; } > --------------------------------------------------------------------------------###########------------------------- > > Running VCC-compiler failed, exit 1 > > VCL compilation failed > > > I've likely missed/misunderstood a required change :-/ > > Here's the relevant snip from my config > > ... > > backend def_SITE1 { .port = "10100"; include > "/usr/local/etc/varnish/backend_common.vcl"; } > backend css_SITE1 { .port = "10101"; include > "/usr/local/etc/varnish/backend_common.vcl"; } > backend js_SITE1 { .port = "10102"; include > "/usr/local/etc/varnish/backend_common.vcl"; } > backend img_SITE1 { .port = "10103"; include > "/usr/local/etc/varnish/backend_common.vcl"; } > > backend def_FALLBACK { .port = "9999"; include > "/usr/local/etc/varnish/backend_common.vcl"; } > > sub hostname_normalize { > if (req.http.host == "www.mydomain.net" ) { > set req.http.host = "mydomain.net"; } > > sub backend_assign { > if (req.http.host == "mydomain.net" ) { > 94 if (req.url ~ > "\.(css|css?.*|woff|eot|svg|ttf|otf)$") { set req.backend = css_SITE1; } > elseif (req.url ~ "\.(js|js?.*)$" > ) { set req.backend = js_SITE1; } > elseif (req.url ~ "\.(jp(e?)g|gif|png|ti(f?)f)$" > ) { set req.backend = img_SITE1; } > else > { set req.backend = def_SITE1; } > } > > ... > > What's "req.backend" need to be changed to? Hi, You need to change it to backend_hint. It is not clearly documented in the "upgrading" page but you can see it on the directors examples. Cheers, Dridi > Grant > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From grantksupport at operamail.com Sun May 4 16:27:50 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 09:27:50 -0700 Subject: Upgrading v3 -> v4; vcl check fails @ req.backend . What have I missed? In-Reply-To: References: <1399219455.16859.113500961.3EFF42DE@webmail.messagingengine.com> Message-ID: <1399220870.21313.113505529.2E03CBD0@webmail.messagingengine.com> Hi Dridi, Thanks! Knowing what to look for, I found the relevant commit at http://www.gossamer-threads.com/lists/varnish/commits/29579 Useful to add to docs, too! Once that's fixed (no more error), I get the NEXT error, Maybe related? According to "req.backend.healthy replaced by std.healthy(req.backend)" I changed in my vcl ... - if (req.backend.healthy) { 223 + if (std.healthy(req.backend)) { set req.grace = 30s; } else { set req.grace = 1h; } ... but config check reports Message from VCC-compiler: Symbol not found: 'std.healthy' (expected type BOOL): ('input' Line 223 Pos 13) if (std.healthy(req.backend)) { ------------###########---------------- Running VCC-compiler failed, exit 1 VCL compilation failed Looking in the examples, too ... Grant On Sun, May 4, 2014, at 09:22 AM, Dridi Boukelmoune wrote: > On Sun, May 4, 2014 at 6:04 PM, wrote: > > Hi, > > > > I've upgraded from Varnish 3 -> 4, and am working on converting my VCL, > > following > > > > "Upgrading to Varnish 4" > > https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html > > > > After making changes as I've understood them, I thing I've gotten most > > right, but on config file check, I still get a fail, > > > > varnishd -C -f vcl.SITE.conf > > Message from VCC-compiler: > > Unknown variable 'req.backend' > > At: ('input' Line 94 Pos 81) > > if (req.url ~ > > "\.(css|css?.*|woff|eot|svg|ttf|otf)$") { set > > req.backend = css_SITE1; } > > --------------------------------------------------------------------------------###########------------------------- > > > > Running VCC-compiler failed, exit 1 > > > > VCL compilation failed > > > > > > I've likely missed/misunderstood a required change :-/ > > > > Here's the relevant snip from my config > > > > ... > > > > backend def_SITE1 { .port = "10100"; include > > "/usr/local/etc/varnish/backend_common.vcl"; } > > backend css_SITE1 { .port = "10101"; include > > "/usr/local/etc/varnish/backend_common.vcl"; } > > backend js_SITE1 { .port = "10102"; include > > "/usr/local/etc/varnish/backend_common.vcl"; } > > backend img_SITE1 { .port = "10103"; include > > "/usr/local/etc/varnish/backend_common.vcl"; } > > > > backend def_FALLBACK { .port = "9999"; include > > "/usr/local/etc/varnish/backend_common.vcl"; } > > > > sub hostname_normalize { > > if (req.http.host == "www.mydomain.net" ) { > > set req.http.host = "mydomain.net"; } > > > > sub backend_assign { > > if (req.http.host == "mydomain.net" ) { > > 94 if (req.url ~ > > "\.(css|css?.*|woff|eot|svg|ttf|otf)$") { set req.backend = css_SITE1; } > > elseif (req.url ~ "\.(js|js?.*)$" > > ) { set req.backend = js_SITE1; } > > elseif (req.url ~ "\.(jp(e?)g|gif|png|ti(f?)f)$" > > ) { set req.backend = img_SITE1; } > > else > > { set req.backend = def_SITE1; } > > } > > > > ... > > > > What's "req.backend" need to be changed to? > > Hi, > > You need to change it to backend_hint. > > It is not clearly documented in the "upgrading" page but you can see > it on the directors examples. > > Cheers, > Dridi > > > Grant > > > > _______________________________________________ > > varnish-misc mailing list > > varnish-misc at varnish-cache.org > > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From grantksupport at operamail.com Sun May 4 16:54:30 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 09:54:30 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" Message-ID: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> Digging around, guess this IS a separate issue. According to "req.backend.healthy replaced by std.healthy(req.backend)" I changed in my vcl ... - if (req.backend.healthy) { 223 + if (std.healthy(req.backend)) { set req.grace = 30s; } else { set req.grace = 1h; } ... but config check reports Message from VCC-compiler: Symbol not found: 'std.healthy' (expected type BOOL): ('input' Line 223 Pos 13) if (std.healthy(req.backend)) { ------------###########---------------- Running VCC-compiler failed, exit 1 VCL compilation failed I found the original commit @ "[master] 351e100 Add BOOL std.healthy(BACKEND) which can check if any backend is healthy, rather than have hardcoded variables for req.backend and bereq.backend's health" https://www.varnish-cache.org/lists/pipermail/varnish-commit/2013-November/010284.html and a question about usage @ "Questiona about req.backend.healthy" https://www.varnish-cache.org/lists/pipermail/varnish-misc/2013-June/023139.html but don't understand the problem. Grant From dridi.boukelmoune at zenika.com Sun May 4 16:57:24 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Sun, 4 May 2014 18:57:24 +0200 Subject: Upgrading v3 -> v4; vcl check fails @ req.backend . What have I missed? In-Reply-To: <1399220870.21313.113505529.2E03CBD0@webmail.messagingengine.com> References: <1399219455.16859.113500961.3EFF42DE@webmail.messagingengine.com> <1399220870.21313.113505529.2E03CBD0@webmail.messagingengine.com> Message-ID: On Sun, May 4, 2014 at 6:27 PM, wrote: > Hi Dridi, > > Thanks! Knowing what to look for, I found the relevant commit at > > http://www.gossamer-threads.com/lists/varnish/commits/29579 > > Useful to add to docs, too! > > Once that's fixed (no more error), I get the NEXT error, Maybe related? > > According to > > "req.backend.healthy replaced by std.healthy(req.backend)" > > I changed in my vcl > > ... > - if (req.backend.healthy) { > 223 + if (std.healthy(req.backend)) { > set req.grace = 30s; > } else { > set req.grace = 1h; > } > ... > > > but config check reports > > Message from VCC-compiler: > Symbol not found: 'std.healthy' (expected type BOOL): > ('input' Line 223 Pos 13) > if (std.healthy(req.backend)) { > ------------###########---------------- > > Running VCC-compiler failed, exit 1 > > VCL compilation failed > > Looking in the examples, too ... I have no idea why it doesn't find the healthy function. Can you run the following command and paste the output? readelf -s /usr/lib64/varnish/vmods/libvmod_std.so | grep vmod_ It might be in a different place on your system. Dridi > Grant > > > On Sun, May 4, 2014, at 09:22 AM, Dridi Boukelmoune wrote: >> On Sun, May 4, 2014 at 6:04 PM, wrote: >> > Hi, >> > >> > I've upgraded from Varnish 3 -> 4, and am working on converting my VCL, >> > following >> > >> > "Upgrading to Varnish 4" >> > https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html >> > >> > After making changes as I've understood them, I thing I've gotten most >> > right, but on config file check, I still get a fail, >> > >> > varnishd -C -f vcl.SITE.conf >> > Message from VCC-compiler: >> > Unknown variable 'req.backend' >> > At: ('input' Line 94 Pos 81) >> > if (req.url ~ >> > "\.(css|css?.*|woff|eot|svg|ttf|otf)$") { set >> > req.backend = css_SITE1; } >> > --------------------------------------------------------------------------------###########------------------------- >> > >> > Running VCC-compiler failed, exit 1 >> > >> > VCL compilation failed >> > >> > >> > I've likely missed/misunderstood a required change :-/ >> > >> > Here's the relevant snip from my config >> > >> > ... >> > >> > backend def_SITE1 { .port = "10100"; include >> > "/usr/local/etc/varnish/backend_common.vcl"; } >> > backend css_SITE1 { .port = "10101"; include >> > "/usr/local/etc/varnish/backend_common.vcl"; } >> > backend js_SITE1 { .port = "10102"; include >> > "/usr/local/etc/varnish/backend_common.vcl"; } >> > backend img_SITE1 { .port = "10103"; include >> > "/usr/local/etc/varnish/backend_common.vcl"; } >> > >> > backend def_FALLBACK { .port = "9999"; include >> > "/usr/local/etc/varnish/backend_common.vcl"; } >> > >> > sub hostname_normalize { >> > if (req.http.host == "www.mydomain.net" ) { >> > set req.http.host = "mydomain.net"; } >> > >> > sub backend_assign { >> > if (req.http.host == "mydomain.net" ) { >> > 94 if (req.url ~ >> > "\.(css|css?.*|woff|eot|svg|ttf|otf)$") { set req.backend = css_SITE1; } >> > elseif (req.url ~ "\.(js|js?.*)$" >> > ) { set req.backend = js_SITE1; } >> > elseif (req.url ~ "\.(jp(e?)g|gif|png|ti(f?)f)$" >> > ) { set req.backend = img_SITE1; } >> > else >> > { set req.backend = def_SITE1; } >> > } >> > >> > ... >> > >> > What's "req.backend" need to be changed to? >> >> Hi, >> >> You need to change it to backend_hint. >> >> It is not clearly documented in the "upgrading" page but you can see >> it on the directors examples. >> >> Cheers, >> Dridi >> >> > Grant >> > >> > _______________________________________________ >> > varnish-misc mailing list >> > varnish-misc at varnish-cache.org >> > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From grantksupport at operamail.com Sun May 4 17:07:05 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 10:07:05 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> Message-ID: <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> Hi Dridi, (Relocating to this separate thread ...) On Sun, May 4, 2014, at 09:57 AM, Dridi Boukelmoune wrote: > I have no idea why it doesn't find the healthy function. > > Can you run the following command and paste the output? > readelf -s /usr/lib64/varnish/vmods/libvmod_std.so | grep vmod_ > > It might be in a different place on your system. > > Dridi readelf -s /usr/lib64/varnish/vmods/libvmod_std.so | grep vmod_ readelf: Error: '/usr/lib64/varnish/vmods/libvmod_std.so': No such file find /usr/local/lib64 -type f -name "*libvmod_std*" /usr/local/lib64/varnish/vmods/libvmod_std.la /usr/local/lib64/varnish/vmods/libvmod_std.a /usr/local/lib64/varnish/vmods/libvmod_std.so readelf -s /usr/local/lib64/varnish/vmods/libvmod_std.so | grep vmod_ 43: 0000000000001be0 238 FUNC GLOBAL DEFAULT 12 vmod_set_ip_tos 45: 0000000000001e00 267 FUNC GLOBAL DEFAULT 12 vmod_tolower 48: 0000000000001ce0 270 FUNC GLOBAL DEFAULT 12 vmod_toupper 49: 0000000000001f20 171 FUNC GLOBAL DEFAULT 12 vmod_random 53: 0000000000002920 986 FUNC GLOBAL DEFAULT 12 vmod_fileread 55: 0000000000002180 347 FUNC GLOBAL DEFAULT 12 vmod_syslog 56: 0000000000002d00 510 FUNC GLOBAL DEFAULT 12 vmod_duration 60: 0000000000001fe0 403 FUNC GLOBAL DEFAULT 12 vmod_log 61: 0000000000003000 574 FUNC GLOBAL DEFAULT 12 vmod_ip 62: 00000000000022e0 206 FUNC GLOBAL DEFAULT 12 vmod_collect 63: 0000000000002f00 250 FUNC GLOBAL DEFAULT 12 vmod_integer 64: 00000000000023c0 200 FUNC GLOBAL DEFAULT 12 vmod_healthy 65: 0000000000002540 598 FUNC GLOBAL DEFAULT 12 vmod_timestamp 67: 00000000000024a0 140 FUNC GLOBAL DEFAULT 12 vmod_port 41: 0000000000000000 0 FILE LOCAL DEFAULT ABS vmod_std.c 42: 00000000000019c0 525 FUNC LOCAL DEFAULT 12 vmod_updown 54: 0000000000000000 0 FILE LOCAL DEFAULT ABS vmod_std_fileread.c 60: 0000000000000000 0 FILE LOCAL DEFAULT ABS vmod_std_conversions.c 75: 0000000000001be0 238 FUNC GLOBAL DEFAULT 12 vmod_set_ip_tos 80: 0000000000002f00 250 FUNC GLOBAL DEFAULT 12 vmod_integer 86: 0000000000001fe0 403 FUNC GLOBAL DEFAULT 12 vmod_log 87: 0000000000001f20 171 FUNC GLOBAL DEFAULT 12 vmod_random 88: 0000000000002920 986 FUNC GLOBAL DEFAULT 12 vmod_fileread 92: 0000000000002d00 510 FUNC GLOBAL DEFAULT 12 vmod_duration 97: 0000000000002540 598 FUNC GLOBAL DEFAULT 12 vmod_timestamp 112: 00000000000024a0 140 FUNC GLOBAL DEFAULT 12 vmod_port 114: 00000000000023c0 200 FUNC GLOBAL DEFAULT 12 vmod_healthy 116: 0000000000003000 574 FUNC GLOBAL DEFAULT 12 vmod_ip 119: 0000000000001e00 267 FUNC GLOBAL DEFAULT 12 vmod_tolower 124: 00000000000022e0 206 FUNC GLOBAL DEFAULT 12 vmod_collect 126: 0000000000001ce0 270 FUNC GLOBAL DEFAULT 12 vmod_toupper 130: 0000000000002180 347 FUNC GLOBAL DEFAULT 12 vmod_syslog which varnishd /usr/local/sbin/varnishd ldd /usr/local/sbin/varnishd linux-vdso.so.1 (0x00007fffae2e6000) libvarnish.so => /usr/local/lib64/varnish/libvarnish.so (0x00007fa946dc5000) librt.so.1 => /lib64/librt.so.1 (0x00007fa946bbd000) libvarnishcompat.so => /usr/local/lib64/varnish/libvarnishcompat.so (0x00007fa9469bb000) libvcc.so => /usr/local/lib64/varnish/libvcc.so (0x00007fa94679a000) libvgz.so => /usr/local/lib64/varnish/libvgz.so (0x00007fa946587000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fa946321000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fa94611d000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fa945f05000) libm.so.6 => /lib64/libm.so.6 (0x00007fa945c02000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa9459e4000) libc.so.6 => /lib64/libc.so.6 (0x00007fa945635000) /lib64/ld-linux-x86-64.so.2 (0x00007fa946fdb000) Grant From grantksupport at operamail.com Sun May 4 17:10:32 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 10:10:32 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> Message-ID: <1399223432.29194.113513373.12669D49@webmail.messagingengine.com> I also just noticed that even though I configure with ... --enable-pcre-jit --with-pcre-config=/usr/local/bin/pcre-config ... and /usr/local/bin/pcre-config --libs -L/usr/local/lib64 -lpcre that the BIN links the SYSTEM libs libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fa946321000) This seems like rpath'ing ... From dridi.boukelmoune at zenika.com Sun May 4 17:13:39 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Sun, 4 May 2014 19:13:39 +0200 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> Message-ID: On Sun, May 4, 2014 at 7:07 PM, wrote: > Hi Dridi, > > (Relocating to this separate thread ...) > > On Sun, May 4, 2014, at 09:57 AM, Dridi Boukelmoune wrote: >> I have no idea why it doesn't find the healthy function. >> >> Can you run the following command and paste the output? >> readelf -s /usr/lib64/varnish/vmods/libvmod_std.so | grep vmod_ >> >> It might be in a different place on your system. >> >> Dridi > > readelf -s /usr/lib64/varnish/vmods/libvmod_std.so | grep vmod_ > readelf: Error: '/usr/lib64/varnish/vmods/libvmod_std.so': No > such file > > find /usr/local/lib64 -type f -name "*libvmod_std*" > /usr/local/lib64/varnish/vmods/libvmod_std.la > /usr/local/lib64/varnish/vmods/libvmod_std.a > /usr/local/lib64/varnish/vmods/libvmod_std.so Ok then, what's the output of the following command? sudo varnishadm param.show vmod_dir Dridi > readelf -s /usr/local/lib64/varnish/vmods/libvmod_std.so | grep vmod_ > 43: 0000000000001be0 238 FUNC GLOBAL DEFAULT 12 > vmod_set_ip_tos > 45: 0000000000001e00 267 FUNC GLOBAL DEFAULT 12 vmod_tolower > 48: 0000000000001ce0 270 FUNC GLOBAL DEFAULT 12 vmod_toupper > 49: 0000000000001f20 171 FUNC GLOBAL DEFAULT 12 vmod_random > 53: 0000000000002920 986 FUNC GLOBAL DEFAULT 12 vmod_fileread > 55: 0000000000002180 347 FUNC GLOBAL DEFAULT 12 vmod_syslog > 56: 0000000000002d00 510 FUNC GLOBAL DEFAULT 12 vmod_duration > 60: 0000000000001fe0 403 FUNC GLOBAL DEFAULT 12 vmod_log > 61: 0000000000003000 574 FUNC GLOBAL DEFAULT 12 vmod_ip > 62: 00000000000022e0 206 FUNC GLOBAL DEFAULT 12 vmod_collect > 63: 0000000000002f00 250 FUNC GLOBAL DEFAULT 12 vmod_integer > 64: 00000000000023c0 200 FUNC GLOBAL DEFAULT 12 vmod_healthy > 65: 0000000000002540 598 FUNC GLOBAL DEFAULT 12 > vmod_timestamp > 67: 00000000000024a0 140 FUNC GLOBAL DEFAULT 12 vmod_port > 41: 0000000000000000 0 FILE LOCAL DEFAULT ABS vmod_std.c > 42: 00000000000019c0 525 FUNC LOCAL DEFAULT 12 vmod_updown > 54: 0000000000000000 0 FILE LOCAL DEFAULT ABS > vmod_std_fileread.c > 60: 0000000000000000 0 FILE LOCAL DEFAULT ABS > vmod_std_conversions.c > 75: 0000000000001be0 238 FUNC GLOBAL DEFAULT 12 > vmod_set_ip_tos > 80: 0000000000002f00 250 FUNC GLOBAL DEFAULT 12 vmod_integer > 86: 0000000000001fe0 403 FUNC GLOBAL DEFAULT 12 vmod_log > 87: 0000000000001f20 171 FUNC GLOBAL DEFAULT 12 vmod_random > 88: 0000000000002920 986 FUNC GLOBAL DEFAULT 12 vmod_fileread > 92: 0000000000002d00 510 FUNC GLOBAL DEFAULT 12 vmod_duration > 97: 0000000000002540 598 FUNC GLOBAL DEFAULT 12 > vmod_timestamp > 112: 00000000000024a0 140 FUNC GLOBAL DEFAULT 12 vmod_port > 114: 00000000000023c0 200 FUNC GLOBAL DEFAULT 12 vmod_healthy > 116: 0000000000003000 574 FUNC GLOBAL DEFAULT 12 vmod_ip > 119: 0000000000001e00 267 FUNC GLOBAL DEFAULT 12 vmod_tolower > 124: 00000000000022e0 206 FUNC GLOBAL DEFAULT 12 vmod_collect > 126: 0000000000001ce0 270 FUNC GLOBAL DEFAULT 12 vmod_toupper > 130: 0000000000002180 347 FUNC GLOBAL DEFAULT 12 vmod_syslog > > which varnishd > /usr/local/sbin/varnishd > > ldd /usr/local/sbin/varnishd > linux-vdso.so.1 (0x00007fffae2e6000) > libvarnish.so => /usr/local/lib64/varnish/libvarnish.so > (0x00007fa946dc5000) > librt.so.1 => /lib64/librt.so.1 (0x00007fa946bbd000) > libvarnishcompat.so => > /usr/local/lib64/varnish/libvarnishcompat.so > (0x00007fa9469bb000) > libvcc.so => /usr/local/lib64/varnish/libvcc.so > (0x00007fa94679a000) > libvgz.so => /usr/local/lib64/varnish/libvgz.so > (0x00007fa946587000) > libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fa946321000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007fa94611d000) > libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fa945f05000) > libm.so.6 => /lib64/libm.so.6 (0x00007fa945c02000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa9459e4000) > libc.so.6 => /lib64/libc.so.6 (0x00007fa945635000) > /lib64/ld-linux-x86-64.so.2 (0x00007fa946fdb000) > > > Grant From grantksupport at operamail.com Sun May 4 17:20:06 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 10:20:06 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> Message-ID: <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> > Ok then, what's the output of the following command? > > sudo varnishadm param.show vmod_dir sudo varnishadm param.show vmod_dir Not a VSM file /usr/local/var/varnish/SITE/_.vsm ls -al /usr/local/var/varnish/SITE/*.vsm -rw-r--r-- 1 root root 81M May 4 08:19 /usr/local/var/varnish/SITE/_.vsm file /usr/local/var/varnish/SITE/_.vsm /usr/local/var/varnish/SITE/_.vsm: data From dridi.boukelmoune at zenika.com Sun May 4 17:23:20 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Sun, 4 May 2014 19:23:20 +0200 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> Message-ID: On Sun, May 4, 2014 at 7:20 PM, wrote: >> Ok then, what's the output of the following command? >> >> sudo varnishadm param.show vmod_dir > > sudo varnishadm param.show vmod_dir > Not a VSM file /usr/local/var/varnish/SITE/_.vsm > > ls -al /usr/local/var/varnish/SITE/*.vsm > -rw-r--r-- 1 root root 81M May 4 08:19 > /usr/local/var/varnish/SITE/_.vsm > > file /usr/local/var/varnish/SITE/_.vsm > /usr/local/var/varnish/SITE/_.vsm: data Is your varnishd instance running ? If not, comment out the vcl that uses the std module and start varnish before running varnishadm. From grantksupport at operamail.com Sun May 4 17:49:16 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 10:49:16 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> Message-ID: <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> > Is your varnishd instance running ? No. It won't run, because the conf file check has errors ... That said, > If not, comment out the vcl that uses the std module and start varnish > before running varnishadm. changing - if (std.healthy(req.backend)) { - set req.grace = 30s; - } else { - set req.grace = 1h; - } + # if (std.healthy(req.backend)) { + # set req.grace = 30s; + # } else { + # set req.grace = 1h; + # } now, at exec of varnishd /usr/local/sbin/varnishd ... Running VCC-compiler failed, exit 1 VCL compilation failed checking varnish -C -f vcl.SITE1.conf Running VCC-compiler failed, exit 1 VCL compilation failed is not very helpful. and of course, varnishd is still not running. From dridi.boukelmoune at zenika.com Sun May 4 18:34:48 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Sun, 4 May 2014 20:34:48 +0200 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> Message-ID: On Sun, May 4, 2014 at 7:49 PM, wrote: >> Is your varnishd instance running ? > > No. It won't run, because the conf file check has errors ... > > That said, > >> If not, comment out the vcl that uses the std module and start varnish >> before running varnishadm. > > changing > > - if (std.healthy(req.backend)) { > - set req.grace = 30s; > - } else { > - set req.grace = 1h; > - } > + # if (std.healthy(req.backend)) { > + # set req.grace = 30s; > + # } else { > + # set req.grace = 1h; > + # } > > now, at exec of varnishd > > /usr/local/sbin/varnishd ... > Running VCC-compiler failed, exit 1 > > VCL compilation failed > > checking > > varnish -C -f vcl.SITE1.conf > Running VCC-compiler failed, exit 1 > > VCL compilation failed > > is not very helpful. and of course, varnishd is still not running. Run it with a dummy VCL, I only want to see whether you need to specify the vmod dir in varnishd's command line. Dridi From grantksupport at operamail.com Sun May 4 18:54:19 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 11:54:19 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> Message-ID: <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> On Sun, May 4, 2014, at 11:34 AM, Dridi Boukelmoune wrote: > Run it with a dummy VCL, I only want to see whether you need to > specify the vmod dir in varnishd's command line. /usr/local/sbin/varnishd -n DUMMY \ -f /usr/local/src/varnish4-cache-git/etc/example.vcl \ -a 127.0.0.1:6081,[::1]:6081 \ -T 127.0.0.1:6082 ps ax | grep varnish 6745 ? SLs 0:00 /usr/local/sbin/varnishd -n DUMMY -f /usr/local/src/varnish4-cache-git/etc/example.vcl -a 127.0.0.1:6081,[::1]:6081 -T 127.0.0.1:6082 6752 ? Sl 0:00 /usr/local/sbin/varnishd -n DUMMY -f /usr/local/src/varnish4-cache-git/etc/example.vcl -a 127.0.0.1:6081,[::1]:6081 -T 127.0.0.1:6082 6992 pts/9 S+ 0:00 grep --color=auto varnish varnishadm param.show vmod_dir Not a VSM file /usr/local/var/varnish/SITE/_.vsm From dridi.boukelmoune at zenika.com Sun May 4 19:14:29 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Sun, 4 May 2014 21:14:29 +0200 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> Message-ID: On Sun, May 4, 2014 at 8:54 PM, wrote: > > > On Sun, May 4, 2014, at 11:34 AM, Dridi Boukelmoune wrote: >> Run it with a dummy VCL, I only want to see whether you need to >> specify the vmod dir in varnishd's command line. > > /usr/local/sbin/varnishd -n DUMMY \ > -f /usr/local/src/varnish4-cache-git/etc/example.vcl \ > -a 127.0.0.1:6081,[::1]:6081 \ > -T 127.0.0.1:6082 > > ps ax | grep varnish > 6745 ? SLs 0:00 /usr/local/sbin/varnishd -n DUMMY -f > /usr/local/src/varnish4-cache-git/etc/example.vcl -a > 127.0.0.1:6081,[::1]:6081 -T 127.0.0.1:6082 > 6752 ? Sl 0:00 /usr/local/sbin/varnishd -n DUMMY -f > /usr/local/src/varnish4-cache-git/etc/example.vcl -a > 127.0.0.1:6081,[::1]:6081 -T 127.0.0.1:6082 > 6992 pts/9 S+ 0:00 grep --color=auto varnish > > varnishadm param.show vmod_dir > Not a VSM file /usr/local/var/varnish/SITE/_.vsm If you use the -n option in varnishd, you must use it accordingly with the other tools (varnishlog, varnishstat etc). Try this: varnishadm -n DUMMY param.show vmod_dir From grantksupport at operamail.com Sun May 4 19:15:35 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 12:15:35 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> Message-ID: <1399230935.19996.113537737.77A09FB4@webmail.messagingengine.com> just fyi, pkg-config --variable=vmoddir varnishapi /usr/local/lib64/varnish/vmods From grantksupport at operamail.com Sun May 4 19:16:48 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 12:16:48 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399230935.19996.113537737.77A09FB4@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> <1399230935.19996.113537737.77A09FB4@webmail.messagingengine.com> Message-ID: <1399231008.20507.113538057.0035A28E@webmail.messagingengine.com> varnishadm -n DUMMY param.show vmod_dir vmod_dir Value is: /usr/local/lib64/varnish/vmods (default) Default is: /usr/local/lib64/varnish/vmods Directory where VCL modules are to be found. From dridi.boukelmoune at zenika.com Sun May 4 19:44:25 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Sun, 4 May 2014 21:44:25 +0200 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399231008.20507.113538057.0035A28E@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> <1399230935.19996.113537737.77A09FB4@webmail.messagingengine.com> <1399231008.20507.113538057.0035A28E@webmail.messagingengine.com> Message-ID: Did you actually import the std module in you VCL ? On Sun, May 4, 2014 at 9:16 PM, wrote: > varnishadm -n DUMMY param.show vmod_dir > vmod_dir > Value is: /usr/local/lib64/varnish/vmods (default) > Default is: /usr/local/lib64/varnish/vmods > > Directory where VCL modules are to be found. From grantksupport at operamail.com Sun May 4 19:48:16 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 12:48:16 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> <1399230935.19996.113537737.77A09FB4@webmail.messagingengine.com> <1399231008.20507.113538057.0035A28E@webmail.messagingengine.com> Message-ID: <1399232896.25903.113544433.7DBA1BA3@webmail.messagingengine.com> On Sun, May 4, 2014, at 12:44 PM, Dridi Boukelmoune wrote: > Did you actually import the std module in you VCL ? No. I'm following https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html#obj-in-vcl-error-replaced-by-beresp-in-vcl-backend-error It did not instruct to do any such import. Looking for how to, now ... From dridi.boukelmoune at zenika.com Sun May 4 19:53:39 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Sun, 4 May 2014 21:53:39 +0200 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: <1399232896.25903.113544433.7DBA1BA3@webmail.messagingengine.com> References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> <1399230935.19996.113537737.77A09FB4@webmail.messagingengine.com> <1399231008.20507.113538057.0035A28E@webmail.messagingengine.com> <1399232896.25903.113544433.7DBA1BA3@webmail.messagingengine.com> Message-ID: On Sun, May 4, 2014 at 9:48 PM, wrote: > > > On Sun, May 4, 2014, at 12:44 PM, Dridi Boukelmoune wrote: >> Did you actually import the std module in you VCL ? > > No. I'm following > > https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html#obj-in-vcl-error-replaced-by-beresp-in-vcl-backend-error > > It did not instruct to do any such import. Good point. Since the std module is not something new, it should probably say something like "import the standard module if you're not already using it". https://www.varnish-cache.org/docs/4.0/reference/vmod.html?highlight=import > Looking for how to, now ... From grantksupport at operamail.com Sun May 4 19:56:59 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 12:56:59 -0700 Subject: upgrading to v4, change of "req.backend.healthy" -> "std.healthy(req.backend)" reports "Symbol not found: 'std.healthy' (expected type BOOL)" In-Reply-To: References: <1399222470.26419.113509653.241EA0B6@webmail.messagingengine.com> <1399223225.28916.113512813.2A9F20B9@webmail.messagingengine.com> <1399224006.31029.113514785.618213F7@webmail.messagingengine.com> <1399225756.3814.113518441.0D0CD00A@webmail.messagingengine.com> <1399229659.16430.113532949.68B4A8C0@webmail.messagingengine.com> <1399230935.19996.113537737.77A09FB4@webmail.messagingengine.com> <1399231008.20507.113538057.0035A28E@webmail.messagingengine.com> <1399232896.25903.113544433.7DBA1BA3@webmail.messagingengine.com> Message-ID: <1399233419.28091.113545585.139DAC86@webmail.messagingengine.com> I added the import std; now, at VCL check of my 'full' vcl, I get simply /usr/local/sbin/varnishd -n TEST -C -f /usr/local/etc/varnish/vcl.TEST.conf Running VCC-compiler failed, exit 1 VCL compilation failed no further info on WHY ... yet. Grant From bluethundr at gmail.com Mon May 5 02:50:38 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Sun, 4 May 2014 22:50:38 -0400 Subject: can't add second node Message-ID: Hey all, I have a very basic entirely stripped down default.vcl that I can't seem to get to work. And I'm unclear as to why. With one node defined I am good and can restart at will: # man page for details on VCL syntax and semantics. # # Default backend definition. Set this to point to your content # server. # probe favicon { .url = "/favicon.ico"; .timeout = 60ms; .interval = 2s; .window = 5; .threshold = 3; } backend web1 { .host = "xx.xx.xx.xx"; .port = "80"; .probe = favicon; } [root at varnish1 varnish]# service varnish restart Stopping Varnish Cache: [ OK ] Starting Varnish Cache: [ OK ] However as soon as I add one more node, vernish fails to start: # man page for details on VCL syntax and semantics. # # Default backend definition. Set this to point to your content # server. # probe favicon { .url = "/favicon.ico"; .timeout = 60ms; .interval = 2s; .window = 5; .threshold = 3; } backend web1 { .host = "xx.xx.xx.xx"; .port = "80"; .probe = favicon; } backend web2 { .host = "xx.xx.xx.xx; .port = "80"; .probe = favicon; } Varnish will not start with this config: [root at varnish1 varnish]# service varnish start Starting Varnish Cache: [FAILED] I was just hoping someone could enlighten me as to why I may be having trouble here! Thanks for any advice you can give. Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.crowder at spechal.com Mon May 5 02:55:56 2014 From: travis.crowder at spechal.com (Travis Crowder) Date: Sun, 4 May 2014 21:55:56 -0500 Subject: can't add second node In-Reply-To: References: Message-ID: Missing quote on second host ip? Sent from my iPhone > On May 4, 2014, at 9:50 PM, Tim Dunphy wrote: > > Hey all, > > I have a very basic entirely stripped down default.vcl that I can't seem to get to work. And I'm unclear as to why. > > > With one node defined I am good and can restart at will: > > # man page for details on VCL syntax and semantics. > # > # Default backend definition. Set this to point to your content > # server. > # > probe favicon { > .url = "/favicon.ico"; > .timeout = 60ms; > .interval = 2s; > .window = 5; > .threshold = 3; > } > > backend web1 { > .host = "xx.xx.xx.xx"; > .port = "80"; > .probe = favicon; > } > > > [root at varnish1 varnish]# service varnish restart > Stopping Varnish Cache: [ OK ] > Starting Varnish Cache: [ OK ] > > > However as soon as I add one more node, vernish fails to start: > > # man page for details on VCL syntax and semantics. > # > # Default backend definition. Set this to point to your content > # server. > # > probe favicon { > .url = "/favicon.ico"; > .timeout = 60ms; > .interval = 2s; > .window = 5; > .threshold = 3; > } > > backend web1 { > .host = "xx.xx.xx.xx"; > .port = "80"; > .probe = favicon; > } > > backend web2 { > .host = "xx.xx.xx.xx; > .port = "80"; > .probe = favicon; > } > Varnish will not start with this config: > > [root at varnish1 varnish]# service varnish start > Starting Varnish Cache: [FAILED] > > I was just hoping someone could enlighten me as to why I may be having trouble here! > > Thanks for any advice you can give. > > Tim > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From guery.b at gmail.com Mon May 5 06:05:10 2014 From: guery.b at gmail.com (=?ISO-8859-1?Q?Boris_Gu=E9ry?=) Date: Mon, 05 May 2014 08:05:10 +0200 Subject: can't add second node In-Reply-To: References: Message-ID: <53672A16.2050708@gmail.com> Hi, use `varnishd -C -f [path to your vcl file]` to lint and dump your compiled VCL. You may also want to start your service in verbose debug mode by running sh -v -x /etc/init.d/varnish start Le 05/05/2014 04:50, Tim Dunphy a ?crit : > Hey all, > > I have a very basic entirely stripped down default.vcl that I > can't seem to get to work. And I'm unclear as to why. > > > With one node defined I am good and can restart at will: > > # man page for details on VCL syntax and semantics. # # Default > backend definition. Set this to point to your content # server. # > probe favicon { .url = "/favicon.ico"; .timeout = 60ms; .interval = > 2s; .window = 5; .threshold = 3; } > > backend web1 { .host = "xx.xx.xx.xx"; .port = "80"; .probe = > favicon; } > > > [root at varnish1 varnish]# service varnish restart Stopping Varnish > Cache: [ OK ] Starting Varnish > Cache: [ OK ] > > > However as soon as I add one more node, vernish fails to start: > > # man page for details on VCL syntax and semantics. # # Default > backend definition. Set this to point to your content # server. # > probe favicon { .url = "/favicon.ico"; .timeout = 60ms; .interval = > 2s; .window = 5; .threshold = 3; } > > backend web1 { .host = "xx.xx.xx.xx"; .port = "80"; .probe = > favicon; } > > backend web2 { .host = "xx.xx.xx.xx; .port = "80"; .probe = > favicon; } Varnish will not start with this config: > > [root at varnish1 varnish]# service varnish start Starting Varnish > Cache: [FAILED] > > I was just hoping someone could enlighten me as to why I may be > having trouble here! > > Thanks for any advice you can give. > > Tim > > -- GPG me!! > > gpg --keyserver pool.sks-keyservers.net > --recv-keys F186197B > > > > _______________________________________________ varnish-misc > mailing list varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- Boris Gu?ry mobile: +33 6 86 83 03 12 twitter: @borisguery skype: borisguery pgp: 0x034C6265 From grantksupport at operamail.com Mon May 5 06:08:27 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Sun, 04 May 2014 23:08:27 -0700 Subject: debugging v4 vcl -- check with "-C" fails, but give no error details Message-ID: <1399270107.22498.113669513.38DC1DAC@webmail.messagingengine.com> I'm plugging away at converting my v3 -> v4 vcl. Made some progress, but right now, when I exec a config check it fails, but provides no details, /usr/local/sbin/varnishd -C -n TEST -f /usr/local/etc/varnish/vcl.TEST.conf Running VCC-compiler failed, exit 1 VCL compilation failed How do I get some idea of what the problem is if the check isn't reporting it? Grant From phk at phk.freebsd.dk Mon May 5 06:13:03 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 05 May 2014 06:13:03 +0000 Subject: debugging v4 vcl -- check with "-C" fails, but give no error details In-Reply-To: <1399270107.22498.113669513.38DC1DAC@webmail.messagingengine.com> References: <1399270107.22498.113669513.38DC1DAC@webmail.messagingengine.com> Message-ID: <81211.1399270383@critter.freebsd.dk> In message <1399270107.22498.113669513.38DC1DAC at webmail.messagingengine.com>, g rantksupport at operamail.com writes: >I'm plugging away at converting my v3 -> v4 vcl. > >Made some progress, but right now, when I exec a config check it fails, >but provides no details, > > /usr/local/sbin/varnishd -C -n TEST -f > /usr/local/etc/varnish/vcl.TEST.conf > Running VCC-compiler failed, exit 1 > > VCL compilation failed Can you send me a copy of that vcl file ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From bluethundr at gmail.com Mon May 5 13:41:24 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Mon, 5 May 2014 09:41:24 -0400 Subject: can't add second node In-Reply-To: References: Message-ID: <5CDA4218-35AF-4985-9AEA-692F7C76A2EA@gmail.com> Whoops! That must be it. Thanks! Sent from my iPhone > On May 4, 2014, at 10:55 PM, Travis Crowder wrote: > > Missing quote on second host ip? > > Sent from my iPhone > >> On May 4, 2014, at 9:50 PM, Tim Dunphy wrote: >> >> Hey all, >> >> I have a very basic entirely stripped down default.vcl that I can't seem to get to work. And I'm unclear as to why. >> >> >> With one node defined I am good and can restart at will: >> >> # man page for details on VCL syntax and semantics. >> # >> # Default backend definition. Set this to point to your content >> # server. >> # >> probe favicon { >> .url = "/favicon.ico"; >> .timeout = 60ms; >> .interval = 2s; >> .window = 5; >> .threshold = 3; >> } >> >> backend web1 { >> .host = "xx.xx.xx.xx"; >> .port = "80"; >> .probe = favicon; >> } >> >> >> [root at varnish1 varnish]# service varnish restart >> Stopping Varnish Cache: [ OK ] >> Starting Varnish Cache: [ OK ] >> >> >> However as soon as I add one more node, vernish fails to start: >> >> # man page for details on VCL syntax and semantics. >> # >> # Default backend definition. Set this to point to your content >> # server. >> # >> probe favicon { >> .url = "/favicon.ico"; >> .timeout = 60ms; >> .interval = 2s; >> .window = 5; >> .threshold = 3; >> } >> >> backend web1 { >> .host = "xx.xx.xx.xx"; >> .port = "80"; >> .probe = favicon; >> } >> >> backend web2 { >> .host = "xx.xx.xx.xx; >> .port = "80"; >> .probe = favicon; >> } >> Varnish will not start with this config: >> >> [root at varnish1 varnish]# service varnish start >> Starting Varnish Cache: [FAILED] >> >> I was just hoping someone could enlighten me as to why I may be having trouble here! >> >> Thanks for any advice you can give. >> >> Tim >> >> -- >> GPG me!! >> >> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From grantksupport at operamail.com Mon May 5 14:13:28 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Mon, 05 May 2014 07:13:28 -0700 Subject: v4 won't (re) start if _.vsm preexists -- starts fine if deleted 1st Message-ID: <1399299208.25861.113795461.08190CF9@webmail.messagingengine.com> Hi, Still working on my v3->v4 upgrade. I've noticed that while v3 stopped/started without any problems, my v4 instance starts -- but only (?) if there's no previous "_.vsm" lying around. Here's what I'm seeing: systemctl start varnish-custom.service -> RUNS/OK ls -al /usr/local/var/varnish/TEST/ total 82M drwxrwxrwt 2 root root 80 May 5 06:55 ./ drwxrwxr-x+ 3 grant users 4.0K May 5 06:05 ../ -rwxr-xr-x 1 nobody nogroup 77K May 5 06:55 vcl.vLB_IZSL.so* -rw-r--r-- 1 root root 81M May 5 06:55 _.vsm systemctl stop varnish-custom.service ls -al /usr/local/var/varnish/TEST/ total 120M drwxrwxrwt 2 root root 80 May 5 06:56 ./ drwxrwxr-x+ 3 grant users 4.0K May 5 06:05 ../ -rw-r--r-- 1 root root 81M May 5 06:55 _.vsm -rw-r--r-- 1 root root 39M May 5 06:56 _.vsm.13175 systemctl start varnish-custom.service Job for varnish-custom.service failed. See 'systemctl status varnish-custom.service' and 'journalctl -xn' for details. systemctl stop varnish-custom.service systemctl start varnish-custom.service Job for varnish-custom.service failed. See 'systemctl status varnish-custom.service' and 'journalctl -xn' for details. systemctl stop varnish-custom.service ls -al /usr/local/var/varnish/TEST/ total 120M drwxrwxrwt 2 root root 80 May 5 06:56 ./ drwxrwxr-x+ 3 grant users 4.0K May 5 06:05 ../ -rw-r--r-- 1 root root 81M May 5 06:55 _.vsm -rw-r--r-- 1 root root 39M May 5 06:56 _.vsm.13175 rm -f /usr/local/var/varnish/TEST/_.vsm* ls -al /usr/local/var/varnish/TEST/ total 4.0K drwxrwxrwt 2 root root 40 May 5 07:01 ./ drwxrwxr-x+ 3 grant users 4.0K May 5 06:05 ../ systemctl start varnish-custom.service -> RUNS/OK ls -al /usr/local/var/varnish/TEST/ total 82M drwxrwxrwt 2 root root 80 May 5 07:03 ./ drwxrwxr-x+ 3 grant users 4.0K May 5 06:05 ../ -rwxr-xr-x 1 nobody nogroup 77K May 5 07:03 vcl.qH7WsF0n.so* -rw-r--r-- 1 root root 81M May 5 07:03 _.vsm Reading here, https://www.varnish-cache.org/docs/trunk/reference/vsm.html, iiuc (?) the vsm should be cleared on stop? I can reproduce this ^^^ on two different machines, so if it's something I'm (not) doing, I'm at least consistent. Grant From aj at andrews-enterprise.co.uk Mon May 5 19:24:25 2014 From: aj at andrews-enterprise.co.uk (Mr A J Andrews-McDermott) Date: Mon, 5 May 2014 20:24:25 +0100 Subject: Kayako Fusion Message-ID: Hey all I have installed kayako fusion on my server I have also installed Wordpress now I have varnish working nicely with wordpress but that was from using public code how do I get it to allow the cookies SWIFT_sessionid, SWIFT_visitor and SWIFT_scloginpassword these cookies information I got from https://kayako.atlassian.net/wiki/display/DOCS/Cookie+use+and+compliance+in+ Kayako+software Please help! And thanks in advanced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Mon May 5 23:33:34 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Tue, 6 May 2014 00:33:34 +0100 Subject: Kayako Fusion In-Reply-To: References: Message-ID: Hi, What does your current VCL look like? It?d be good to get a look at that first. You might be able to do something in `vcl_recv` with `req.http.Cookie`. Thanks, Andrew ? ? Andrew Langhorn GOV.UK Web Operations Government Digital Service On 5 May 2014 at 20:27:29, Mr A J Andrews-McDermott (aj at andrews-enterprise.co.uk) wrote: Hey all I have installed kayako fusion on my server I have also installed Wordpress now I have varnish working nicely with wordpress but that was from using public code how do I get it to allow the cookies SWIFT_sessionid, SWIFT_visitor and SWIFT_scloginpassword these cookies information I got from https://kayako.atlassian.net/wiki/display/DOCS/Cookie+use+and+compliance+in+Kayako+software Please help! ? And thanks in advanced. _______________________________________________ varnish-misc mailing list varnish-misc at varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Mon May 5 23:44:51 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Tue, 6 May 2014 00:44:51 +0100 Subject: Kayako Fusion Message-ID: Thanks. I?ll mull it over tomorrow. Firing this back in to the mailing list loop for posterity, and also in case anyone has any tips before I come up with one. ?? Andrew Langhorn GOV.UK Web Operations Government Digital Service On 6 May 2014 at 00:39:55, aj at andrews-enterprise.co.uk (aj at andrews-enterprise.co.uk) wrote: For ease of access you can view my current config at www.Andrews-enterprise.co.uk/varnish.txt Sent from my HTC ----- Reply message ----- From: "Andrew Langhorn" To: , Subject: Kayako Fusion Date: Tue, May 6, 2014 00:33 Hi, What does your current VCL look like? It?d be good to get a look at that first. You might be able to do something in `vcl_recv` with `req.http.Cookie`. Thanks, Andrew ? ? Andrew Langhorn GOV.UK Web Operations Government Digital Service On 5 May 2014 at 20:27:29, Mr A J Andrews-McDermott (aj at andrews-enterprise.co.uk) wrote: Hey all I have installed kayako fusion on my server I have also installed Wordpress now I have varnish working nicely with wordpress but that was from using public code how do I get it to allow the cookies SWIFT_sessionid, SWIFT_visitor and SWIFT_scloginpassword these cookies information I got from https://kayako.atlassian.net/wiki/display/DOCS/Cookie+use+and+compliance+in+Kayako+software Please help! ? And thanks in advanced. _______________________________________________ varnish-misc mailing list varnish-misc at varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluethundr at gmail.com Tue May 6 02:49:48 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Mon, 5 May 2014 22:49:48 -0400 Subject: can't add second node In-Reply-To: <5CDA4218-35AF-4985-9AEA-692F7C76A2EA@gmail.com> References: <5CDA4218-35AF-4985-9AEA-692F7C76A2EA@gmail.com> Message-ID: Guys, I've got this sorted out. Once I was able to produce verbose output on trying to start varnish with `varnishd -C -f [path to your vcl file]` I realized that what I was getting with adding the second node was the 'backend not used' error in varnish. So then I tried adding a load balancing section like so: director www round-robin { { .backend = web1 ; } { .backend = web2 ; } } But then I saw that I was still getting the backend not used error, so I googled it and found that I had to add the following section to my VCL: sub vcl_recv { set req.backend = www; } Once I did that, everything fell into place. Varnish is now started and working. Thank you! Tim On Mon, May 5, 2014 at 9:41 AM, Tim Dunphy wrote: > Whoops! That must be it. Thanks! > > Sent from my iPhone > > On May 4, 2014, at 10:55 PM, Travis Crowder > wrote: > > Missing quote on second host ip? > > Sent from my iPhone > > On May 4, 2014, at 9:50 PM, Tim Dunphy wrote: > > Hey all, > > I have a very basic entirely stripped down default.vcl that I can't seem > to get to work. And I'm unclear as to why. > > > With one node defined I am good and can restart at will: > > # man page for details on VCL syntax and semantics. > # > # Default backend definition. Set this to point to your content > # server. > # > probe favicon { > .url = "/favicon.ico"; > .timeout = 60ms; > .interval = 2s; > .window = 5; > .threshold = 3; > } > > backend web1 { > .host = "xx.xx.xx.xx"; > .port = "80"; > .probe = favicon; > } > > > [root at varnish1 varnish]# service varnish restart > Stopping Varnish Cache: [ OK ] > Starting Varnish Cache: [ OK ] > > > However as soon as I add one more node, vernish fails to start: > > # man page for details on VCL syntax and semantics. > # > # Default backend definition. Set this to point to your content > # server. > # > probe favicon { > .url = "/favicon.ico"; > .timeout = 60ms; > .interval = 2s; > .window = 5; > .threshold = 3; > } > > backend web1 { > .host = "xx.xx.xx.xx"; > .port = "80"; > .probe = favicon; > } > > backend web2 { > .host = "xx.xx.xx.xx; > .port = "80"; > .probe = favicon; > } > Varnish will not start with this config: > > [root at varnish1 varnish]# service varnish start > Starting Varnish Cache: [FAILED] > > I was just hoping someone could enlighten me as to why I may be having > trouble here! > > Thanks for any advice you can give. > > Tim > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.pascarella at sportnetwork.it Tue May 6 08:58:20 2014 From: g.pascarella at sportnetwork.it (Giuseppe Pascarella) Date: Tue, 06 May 2014 10:58:20 +0200 Subject: Upgrade v3 -> v4 req.grace in vcl_recv In-Reply-To: <5368A3AE.9050004@sportnetwork.it> References: <5368A3AE.9050004@sportnetwork.it> Message-ID: <5368A42C.6090702@sportnetwork.it> Hi, the grace variable is not found in req object. The sample code to activate grace mode, as reported at https://www.varnish-cache.org/docs/trunk/users-guide/vcl-grace.html will not work sub vcl_recv { set req.grace = 15s; } Unknown variable 'req.grace' At: ('input' Line 46 Pos 9) set req.grace = 10m; --------#########------- How can I fix this? Thanks! -- Giuseppe Pascarella Chief Technology Officer @ Divisione Multimedia Sport Network SRL t: +39.06.49.246.423 m: +39.338.733.61.93 Ai sensi della legge 196/2003, si precisa che le informazioni contenute in questo messaggio e nei suoi eventuali allegati sono riservate e per uso esclusivo del destinatario. Nessuno, all'infuori dello stesso deve copiare o distribuire il messaggio o parte di esso a terzi. Chiunque riceva questo messaggio per errore e' pregato di informare immediatamente il mittente e distruggerlo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apj at mutt.dk Tue May 6 09:05:12 2014 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Tue, 6 May 2014 11:05:12 +0200 Subject: Upgrade v3 -> v4 req.grace in vcl_recv In-Reply-To: <5368A42C.6090702@sportnetwork.it> References: <5368A3AE.9050004@sportnetwork.it> <5368A42C.6090702@sportnetwork.it> Message-ID: <20140506090512.GQ19870@nerd.dk> On Tue, May 06, 2014 at 10:58:20AM +0200, Giuseppe Pascarella wrote: > > Unknown variable 'req.grace' > At: ('input' Line 46 Pos 9) > set req.grace = 10m; > --------#########------- > > How can I fix this? The grace logic has been moved to VCL. Tweak the conditionals in the builtin vcl_hit to achieve what you want. -- Andreas From g.pascarella at sportnetwork.it Tue May 6 09:45:14 2014 From: g.pascarella at sportnetwork.it (Giuseppe Pascarella) Date: Tue, 06 May 2014 11:45:14 +0200 Subject: Upgrade v3 -> v4 req.grace in vcl_recv In-Reply-To: <20140506090512.GQ19870@nerd.dk> References: <20140506090512.GQ19870@nerd.dk> Message-ID: <5368AF2A.2060907@sportnetwork.it> I just want the grace mechanism to work. So I need to skip at all the check in vcl_recv? if (!std.healthy(req.backend_hint)) { set req.grace = 10m; } else { set req.grace = 2m; } As reported in https://www.varnish-cache.org/docs/trunk/users-guide/vcl-grace.html "in order to enable Varnish to actually serve the stale object we *must* enable this on the request". -- Giuseppe Pascarella Chief Technology Officer @ Divisione Multimedia Sport Network SRL t: +39.06.49.246.423 m: +39.338.733.61.93 Ai sensi della legge 196/2003, si precisa che le informazioni contenute in questo messaggio e nei suoi eventuali allegati sono riservate e per uso esclusivo del destinatario. Nessuno, all'infuori dello stesso deve copiare o distribuire il messaggio o parte di esso a terzi. Chiunque riceva questo messaggio per errore e' pregato di informare immediatamente il mittente e distruggerlo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Tue May 6 10:27:41 2014 From: perbu at varnish-software.com (Per Buer) Date: Tue, 6 May 2014 12:27:41 +0200 Subject: Upgrade v3 -> v4 req.grace in vcl_recv In-Reply-To: <5368AF2A.2060907@sportnetwork.it> References: <20140506090512.GQ19870@nerd.dk> <5368AF2A.2060907@sportnetwork.it> Message-ID: Yes. req.grace is gone. The docs need an update. Have a look at the builtin VCL (vcl_hit) and you'll see how it works. 2014-05-06 11:45 GMT+02:00 Giuseppe Pascarella : > I just want the grace mechanism to work. > So I need to skip at all the check in vcl_recv? > > if (!std.healthy(req.backend_hint)) { > set req.grace = 10m; > } else { > set req.grace = 2m; > } > > As reported in > https://www.varnish-cache.org/docs/trunk/users-guide/vcl-grace.html "in > order to enable Varnish to actually serve the stale object we *must* enable > this on the request". > > -- > Giuseppe Pascarella > Chief Technology Officer @ Divisione Multimedia > Sport Network SRL > t: +39.06.49.246.423 > m: +39.338.733.61.93 > > Ai sensi della legge 196/2003, si precisa che le informazioni > contenute in questo messaggio e nei suoi eventuali allegati sono > riservate e per uso esclusivo del destinatario. Nessuno, all'infuori > dello stesso deve copiare o distribuire il messaggio o parte di esso a > terzi. Chiunque riceva questo messaggio per errore ? pregato di > informare immediatamente il mittente e distruggerlo. > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.pascarella at sportnetwork.it Tue May 6 10:30:41 2014 From: g.pascarella at sportnetwork.it (Giuseppe Pascarella) Date: Tue, 06 May 2014 12:30:41 +0200 Subject: Upgrade v3 -> v4 req.grace in vcl_recv In-Reply-To: References: Message-ID: <5368B9D1.8040306@sportnetwork.it> Thanks a lot! Ai sensi della legge 196/2003, si precisa che le informazioni contenute in questo messaggio e nei suoi eventuali allegati sono riservate e per uso esclusivo del destinatario. Nessuno, all'infuori dello stesso deve copiare o distribuire il messaggio o parte di esso a terzi. Chiunque riceva questo messaggio per errore e' pregato di informare immediatamente il mittente e distruggerlo. From perbu at varnish-software.com Tue May 6 12:43:16 2014 From: perbu at varnish-software.com (Per Buer) Date: Tue, 6 May 2014 14:43:16 +0200 Subject: Upgrade v3 -> v4 req.grace in vcl_recv In-Reply-To: <5368B9D1.8040306@sportnetwork.it> References: <5368B9D1.8040306@sportnetwork.it> Message-ID: I've update the docs to reflect reality now. I haven't tested it but it seems sane to me. If anybody notices anything wrong let me know. https://www.varnish-cache.org/docs/trunk/users-guide/vcl-grace.html 2014-05-06 12:30 GMT+02:00 Giuseppe Pascarella : > Thanks a lot! > > > > Ai sensi della legge 196/2003, si precisa che le informazioni > contenute in questo messaggio e nei suoi eventuali allegati sono > riservate e per uso esclusivo del destinatario. Nessuno, all'infuori > dello stesso deve copiare o distribuire il messaggio o parte di esso a > terzi. Chiunque riceva questo messaggio per errore e' pregato di > > informare immediatamente il mittente e distruggerlo. > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.pascarella at sportnetwork.it Tue May 6 13:37:14 2014 From: g.pascarella at sportnetwork.it (Giuseppe Pascarella) Date: Tue, 06 May 2014 15:37:14 +0200 Subject: Upgrade v3 -> v4 beresp.url in vcl_backend_response Message-ID: <5368E58A.9060401@sportnetwork.it> Another small issue on v3 vs v4. In vcl_backend_response (ex. vcl_fetch) I used to override default ttl, as suggested in: https://www.varnish-cache.org/docs/trunk/users-guide/increasing-your-hitrate.html sub vcl_backend_response { if (bereq.url ~ "^/legacy_broken_cms/") { set beresp.ttl = 5d; } } Now bereq has no url attribute, how can I implement the same override functionality? Thanks again! -- Giuseppe Pascarella Chief Technology Officer @ Divisione Multimedia Sport Network SRL t: +39.06.49.246.423 m: +39.338.733.61.93 Ai sensi della legge 196/2003, si precisa che le informazioni contenute in questo messaggio e nei suoi eventuali allegati sono riservate e per uso esclusivo del destinatario. Nessuno, all'infuori dello stesso deve copiare o distribuire il messaggio o parte di esso a terzi. Chiunque riceva questo messaggio per errore e' pregato di informare immediatamente il mittente e distruggerlo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apj at mutt.dk Tue May 6 13:43:21 2014 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Tue, 6 May 2014 15:43:21 +0200 Subject: Upgrade v3 -> v4 beresp.url in vcl_backend_response In-Reply-To: <5368E58A.9060401@sportnetwork.it> References: <5368E58A.9060401@sportnetwork.it> Message-ID: <20140506134321.GR19870@nerd.dk> On Tue, May 06, 2014 at 03:37:14PM +0200, Giuseppe Pascarella wrote: > Another small issue on v3 vs v4. > In vcl_backend_response (ex. vcl_fetch) I used to override default > ttl, as suggested in: > > https://www.varnish-cache.org/docs/trunk/users-guide/increasing-your-hitrate.html > > sub vcl_backend_response { > if (bereq.url ~ "^/legacy_broken_cms/") { > set beresp.ttl = 5d; > } > } > > Now bereq has no url attribute, how can I implement the same > override functionality? Yes it does, and the above works for me. -- Andreas From g.pascarella at sportnetwork.it Tue May 6 14:15:05 2014 From: g.pascarella at sportnetwork.it (Giuseppe Pascarella) Date: Tue, 06 May 2014 16:15:05 +0200 Subject: Upgrade v3 -> v4 beresp.url in vcl_backend_response In-Reply-To: <20140506134321.GR19870@nerd.dk> References: <20140506134321.GR19870@nerd.dk> Message-ID: <5368EE69.50305@sportnetwork.it> Sorry, my bad. I was testing the old beresp object in vcl_backend_response. Thanks! -- Giuseppe Pascarella Chief Technology Officer @ Divisione Multimedia Sport Network SRL t: +39.06.49.246.423 m: +39.338.733.61.93 Ai sensi della legge 196/2003, si precisa che le informazioni contenute in questo messaggio e nei suoi eventuali allegati sono riservate e per uso esclusivo del destinatario. Nessuno, all'infuori dello stesso deve copiare o distribuire il messaggio o parte di esso a terzi. Chiunque riceva questo messaggio per errore e' pregato di informare immediatamente il mittente e distruggerlo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluethundr at gmail.com Wed May 7 02:27:05 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Tue, 6 May 2014 22:27:05 -0400 Subject: if (req.restarts == 0) VCL Error Message-ID: Hey All, I'm trying to write a VCL subroutine. The purpose of the section I am having a problem with is to set some headers when it encounters a restart condition. Here's the code. sub vcl_recv { if (req.restarts == 0) { if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip; } else { set req.http.X-Forwarded-For = client.ip; } } if (req.request != "GET"&&req.request != "HEAD") { return (pass); } set req.backend = www; } And here is the error I'm getting: [root at varnish1 varnish]# varnishd -C -f default.vcl Message from VCC-compiler: Syntax error at ('input' Line 39 Pos 30) if (req.restarts == 0) { -----------------------------#- Running VCC-compiler failed, exit 1 VCL compilation failed I'm not entirely sure why, but it looks as if the phrase: if (req.restarts == 0) Is causing it to error out. If I remove that one condition, the VCL does work! So if we're left with just: sub vcl_recv { if (req.request != "GET"&&req.request != "HEAD") { return (pass); } set req.backend = www; In the sub vcl looks like we're ok! [root at varnish1 varnish]# service varnish reload Loading vcl from /etc/varnish/default.vcl Current running config name is reload_2014-05-06T22:13:17 Using new config name reload_2014-05-06T22:26:27 VCL compiled. available 0 boot available 6 reload_2014-05-06T22:13:17 active 0 reload_2014-05-06T22:26:27 Done I would definitely appreciate any advice you may have as to why the above condition is not working. Thanks, Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mike.Bailey at apn.co.nz Wed May 7 03:19:54 2014 From: Mike.Bailey at apn.co.nz (Mike Bailey) Date: Wed, 7 May 2014 03:19:54 +0000 Subject: rpmbuild vmod-header woes Message-ID: <08F4D10AA54CBD4088E589653E30E6FAD4DCF6@APNNZLAKLESM001.APN.NZ> Hi, We have been tasked with compiling/supporting several VMods. Among them is vmod-header https://github.com/varnish/libvmod-header We will be deploying these VMods across a number of varnish servers [Red Hat Enterprise Linux Server release 6.5 (Santiago)] Because of the number of servers; we are using rpmbuild to create a binary pkg for deployment. However the compilation has been a real effort. I have rpmbuild compiling the VMod code itself, but now there seems to be problems with creating the 64bit libraries or at least the of a 64bit library path. The VMod code is somewhat dated (Oct 2012) so I thought perhaps there is something changes/dependencies that I am missing ? I am finding it difficult to google any links for " VMod" and "rpmbuild". A simple compile of the code works fine no issues. I was able to rpmbuild vmod-curl earlier today with virtually no issues. I really think this is primarily an rpmbuild issue, but perhaps someone reading this maillist might have some suggestions. Thx in advance, I have listed the rpmbuild spec file and a tail of the rpmbuild output Summary: Header VMOD for Varnish %{VARNISHVER} Name: vmod-header Version: 0.1 Release: 1%{?dist} License: BSD Group: System Environment/Daemons Source0: ./libvmod-header.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: varnish > 3.0 BuildRequires: make, autoconf, automake, libtool, python-docutils %description Header VMOD for Varnish %{VARNISHVER}. %prep %setup -n libvmod-header %build # this assumes that VARNISHSRC is defined on the rpmbuild command line, like this: # rpmbuild -bb --define 'VARNISHSRC /home/user/rpmbuild/BUILD/varnish-3.0.3' redhat/*spec ./configure VARNISHSRC=%{VARNISHSRC} VMODDIR="$(PKG_CONFIG_PATH=%{VARNISHSRC} pkg-config --variable=vmoddir varnishapi)" --prefix=/usr/ --docdir='${datarootdir}/doc/%{name}' make make check %install make install DESTDIR=%{buildroot} %clean rm -rf %{buildroot} %files %defattr(-,root,root,-) %{_libdir}/varnish/vmods/ %doc /usr/share/doc/%{name}/* %{_mandir}/man?/* %changelog * Wed Oct 03 2012 Lasse Karstensen > - 0.1-0.20120918 - Initial version. .................. Making install in src make[1]: Entering directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header/src' make[2]: Entering directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header/src' make[2]: Nothing to be done for `install-exec-am'. test -z "/usr/local/lib/varnish/vmods" || /bin/mkdir -p "/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods" /bin/sh ../libtool --mode=install /usr/bin/install -c libvmod_header.la '/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods' libtool: install: /usr/bin/install -c .libs/libvmod_header.so /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.so libtool: install: /usr/bin/install -c .libs/libvmod_header.lai /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.la libtool: install: /usr/bin/install -c .libs/libvmod_header.a /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.a libtool: install: chmod 644 /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.a libtool: install: ranlib /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.a libtool: install: warning: remember to run `libtool --finish /usr/local/lib/varnish/vmods' make[2]: Leaving directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header/src' make[1]: Leaving directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header/src' make[1]: Entering directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header' make[2]: Entering directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header' make[2]: Nothing to be done for `install-exec-am'. test -z "/usr/share/doc/vmod-header" || /bin/mkdir -p "/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/share/doc/vmod-header" /usr/bin/install -c -m 644 README.rst LICENSE '/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/share/doc/vmod-header' test -z "/usr/share/man/man3" || /bin/mkdir -p "/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/share/man/man3" /usr/bin/install -c -m 644 vmod_header.3 '/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/share/man/man3' make[2]: Leaving directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header' make[1]: Leaving directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header' + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /home/mrbuild/rpmbuild/BUILD/libvmod-header extracting debug info from /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.so 133 blocks + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-python-bytecompile + /usr/lib/rpm/redhat/brp-python-hardlink + /usr/lib/rpm/redhat/brp-java-repack-jars Processing files: vmod-header-0.1-1.el6.x86_64 error: File not found: /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/lib64/varnish/vmods -mike [APN NZ Media] Mike Bailey Senior Linux Administrator P: 09 373 9554 M: 022 040 2787 E: mike.bailey at apn.co.nz ______________________________________________________________________ NOTICE This email and any attachments are strictly confidential and subject to copyright. They may contain privileged information. If you are not the intended recipient please delete the message and notify the sender. You should not read, copy, use, change, alter or disclose this email or its attachments without authorisation. The company and any related or associated companies do not accept any liability in connection with this email and any attachments including in connection with computer viruses, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Any views expressed in this email and any attachments do not necessarily reflect the views of the company or the views of any of our related or associated companies. ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2963 bytes Desc: image001.jpg URL: From perbu at varnish-software.com Wed May 7 06:52:23 2014 From: perbu at varnish-software.com (Per Buer) Date: Wed, 7 May 2014 08:52:23 +0200 Subject: if (req.restarts == 0) VCL Error In-Reply-To: References: Message-ID: Hi Tim. On Wed, May 7, 2014 at 4:27 AM, Tim Dunphy wrote: > Hey All, > > I'm trying to write a VCL subroutine. The purpose of the section I am > having a problem with is to set some headers when it encounters a restart > condition. Here's the code. > > sub vcl_recv { > if (req.restarts == 0) { > if (req.http.x-forwarded-for) { > set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " > + client.ip; > } else { > set req.http.X-Forwarded-For = client.ip; } > } > > if (req.request != "GET"&&req.request != "HEAD") { > return (pass); > } > > set req.backend = www; > } > FWIW, I took the above code, put it in a file, along with a backend named www and the code compiled and loaded just fine. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluethundr at gmail.com Wed May 7 15:17:11 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Wed, 7 May 2014 11:17:11 -0400 Subject: if (req.restarts == 0) VCL Error In-Reply-To: References: Message-ID: Oh interesting. I think I may have had a slight formatting issue. I've tried copying the code into my VCL again and it ran fine. Sorry for the false alarm. Hope I didn't waste anyone's time. Thanks Tim On Wed, May 7, 2014 at 2:52 AM, Per Buer wrote: > Hi Tim. > > > On Wed, May 7, 2014 at 4:27 AM, Tim Dunphy wrote: > >> Hey All, >> >> I'm trying to write a VCL subroutine. The purpose of the section I am >> having a problem with is to set some headers when it encounters a restart >> condition. Here's the code. >> >> sub vcl_recv { >> if (req.restarts == 0) { >> if (req.http.x-forwarded-for) { >> set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " >> + client.ip; >> } else { >> set req.http.X-Forwarded-For = client.ip; } >> } >> >> if (req.request != "GET"&&req.request != "HEAD") { >> return (pass); >> } >> >> set req.backend = www; >> } >> > > FWIW, I took the above code, put it in a file, along with a backend named > www and the code compiled and loaded just fine. > > > -- > *Per Buer* > CTO | Varnish Software > Phone: +47 958 39 117 | Skype: per.buer > We Make Websites Fly! > > Winner of the Red Herring Top 100 Global Award 2013 > > > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From PaytonK at email.chop.edu Wed May 7 17:58:48 2014 From: PaytonK at email.chop.edu (Payton, Joy J) Date: Wed, 7 May 2014 17:58:48 +0000 Subject: removal and reinstallation Message-ID: Hi all, I had an unused Varnish 3.0.x on a RHEL web server that I just removed. I want to replace it with Varnish 4 (if that is, as I seem to think, the most recent stable release, with additional security features). I previously used the instructions here (https://www.varnish-cache.org/installation/redhat), but they cite the varnish 3 rpm. There's a ton of rpms for Varnish 4 in the repo site... can anyone advise as to which rpm would be appropriate for RHEL 6? I suspect that the new url would be http://repo.varnish-cache.org/redhat/varnish-4.0/el6/src/varnish/varnish-4.0.0-1.el6.src.rpm but I'm not sure... Thanks! Joy Joy Payton Research IS Web Services The Children's Hospital of Philadelphia Research Institute Colket Translational Research Building 2200-30 O: (267) 426 7658 (Internally X67658) F: (267) 426-0130 We advance the health of children by turning scientific discovery into medical innovation. great service --> great discoveries Have I provided you with great service that powers your great discoveries? Tell me about it in my anonymous feedback survey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mike.Bailey at apn.co.nz Fri May 9 00:36:21 2014 From: Mike.Bailey at apn.co.nz (Mike Bailey) Date: Fri, 9 May 2014 00:36:21 +0000 Subject: rpmbuild vmod-header woes In-Reply-To: <4C05E8CB-1692-46A0-A022-76EE8435CF8B@jasonwoods.me.uk> References: <08F4D10AA54CBD4088E589653E30E6FAD4DCF6@APNNZLAKLESM001.APN.NZ> <4C05E8CB-1692-46A0-A022-76EE8435CF8B@jasonwoods.me.uk> Message-ID: <08F4D10AA54CBD4088E589653E30E6FAD4ECD1@APNNZLAKLESM001.APN.NZ> Hi Jason, Thx for you reply. ? Following your suggestion I updated the spec file to call configure as a macro rather than from the command line ? The rpmbuild pkgs were in place ? To kludge my way around the issue with the missing lib64 directory tree I slung a few shell commands under the %install macro to create the directory tree and then move the libraries into place o mkdir -p %{buildroot}/usr/lib64/varnish/vmods %{buildroot}/usr/share/doc/vmod-header o mv %{buildroot}/usr/local/lib/varnish/vmods/libvmod_header.a %{buildroot}/usr/lib64/varnish/vmods/ o mv %{buildroot}/usr/local/lib/varnish/vmods/libvmod_header.la %{buildroot}/usr/lib64/varnish/vmods/ o mv %{buildroot}/usr/local/lib/varnish/vmods/libvmod_header.so %{buildroot}/usr/lib64/varnish/vmods/ Still have to test the rpm pkg to see if it works with our varnish development environment Thx again ! [APN NZ Media] Mike Bailey Senior Linux Administrator P: 09 373 9554 M: 022 040 2787 E: mike.bailey at apn.co.nz From: Jason Woods [mailto:devel at jasonwoods.me.uk] Sent: Wednesday, 7 May 2014 5:58 p.m. To: Mike Bailey Subject: Re: rpmbuild vmod-header woes Hi Mike On 7 May 2014, at 04:19, Mike Bailey > wrote: Hi, We have been tasked with compiling/supporting several VMods. Among them is vmod-header https://github.com/varnish/libvmod-header We will be deploying these VMods across a number of varnish servers [Red Hat Enterprise Linux Server release 6.5 (Santiago)] Because of the number of servers; we are using rpmbuild to create a binary pkg for deployment. However the compilation has been a real effort. I have rpmbuild compiling the VMod code itself, but now there seems to be problems with creating the 64bit libraries or at least the of a 64bit library path. The VMod code is somewhat dated (Oct 2012) so I thought perhaps there is something changes/dependencies that I am missing ? I am finding it difficult to google any links for ? VMod? and ?rpmbuild?. A simple compile of the code works fine no issues. I was able to rpmbuild vmod-curl earlier today with virtually no issues. I really think this is primarily an rpmbuild issue, but perhaps someone reading this maillist might have some suggestions. Thx in advance, I have listed the rpmbuild spec file and a tail of the rpmbuild output Summary: Header VMOD for Varnish %{VARNISHVER} Name: vmod-header Version: 0.1 Release: 1%{?dist} License: BSD Group: System Environment/Daemons Source0: ./libvmod-header.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Requires: varnish > 3.0 BuildRequires: make, autoconf, automake, libtool, python-docutils %description Header VMOD for Varnish %{VARNISHVER}. %prep %setup -n libvmod-header %build # this assumes that VARNISHSRC is defined on the rpmbuild command line, like this: # rpmbuild -bb --define 'VARNISHSRC /home/user/rpmbuild/BUILD/varnish-3.0.3' redhat/*spec ./configure VARNISHSRC=%{VARNISHSRC} VMODDIR="$(PKG_CONFIG_PATH=%{VARNISHSRC} pkg-config --variable=vmoddir varnishapi)" --prefix=/usr/ --docdir='${datarootdir}/doc/%{name}' You aren't passing full path info here so libraries may end up in /lib instead of /lib64 etc Usually the minimum is --prefix and --libdir but it all depends on the program's defaults. Easiest way is make sure rpm-build-macro package is installed (I think it's called that) - it contains all the RedHat specific stuff. Then use %configure instead of ./configure. It will expand to a large ./configure containing all necessary paths. Regards, Jason make make check %install make install DESTDIR=%{buildroot} %clean rm -rf %{buildroot} %files %defattr(-,root,root,-) %{_libdir}/varnish/vmods/ %doc /usr/share/doc/%{name}/* %{_mandir}/man?/* %changelog * Wed Oct 03 2012 Lasse Karstensen > - 0.1-0.20120918 - Initial version. .................. Making install in src make[1]: Entering directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header/src' make[2]: Entering directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header/src' make[2]: Nothing to be done for `install-exec-am'. test -z "/usr/local/lib/varnish/vmods" || /bin/mkdir -p "/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods" /bin/sh ../libtool --mode=install /usr/bin/install -c libvmod_header.la '/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods' libtool: install: /usr/bin/install -c .libs/libvmod_header.so /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.so libtool: install: /usr/bin/install -c .libs/libvmod_header.lai /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.la libtool: install: /usr/bin/install -c .libs/libvmod_header.a /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.a libtool: install: chmod 644 /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.a libtool: install: ranlib /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.a libtool: install: warning: remember to run `libtool --finish /usr/local/lib/varnish/vmods' make[2]: Leaving directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header/src' make[1]: Leaving directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header/src' make[1]: Entering directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header' make[2]: Entering directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header' make[2]: Nothing to be done for `install-exec-am'. test -z "/usr/share/doc/vmod-header" || /bin/mkdir -p "/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/share/doc/vmod-header" /usr/bin/install -c -m 644 README.rst LICENSE '/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/share/doc/vmod-header' test -z "/usr/share/man/man3" || /bin/mkdir -p "/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/share/man/man3" /usr/bin/install -c -m 644 vmod_header.3 '/home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/share/man/man3' make[2]: Leaving directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header' make[1]: Leaving directory `/home/mrbuild/rpmbuild/BUILD/libvmod-header' + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /home/mrbuild/rpmbuild/BUILD/libvmod-header extracting debug info from /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/local/lib/varnish/vmods/libvmod_header.so 133 blocks + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump + /usr/lib/rpm/brp-python-bytecompile + /usr/lib/rpm/redhat/brp-python-hardlink + /usr/lib/rpm/redhat/brp-java-repack-jars Processing files: vmod-header-0.1-1.el6.x86_64 error: File not found: /home/mrbuild/rpmbuild/BUILDROOT/vmod-header-0.1-1.el6.x86_64/usr/lib64/varnish/vmods -mike Mike Bailey Senior Linux Administrator P: 09 373 9554 M: 022 040 2787 E: mike.bailey at apn.co.nz ______________________________________________________________________ NOTICE This email and any attachments are strictly confidential and subject to copyright. They may contain privileged information. If you are not the intended recipient please delete the message and notify the sender. You should not read, copy, use, change, alter or disclose this email or its attachments without authorisation. The company and any related or associated companies do not accept any liability in connection with this email and any attachments including in connection with computer viruses, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Any views expressed in this email and any attachments do not necessarily reflect the views of the company or the views of any of our related or associated companies. ______________________________________________________________________ _______________________________________________ varnish-misc mailing list varnish-misc at varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc ______________________________________________________________________ NOTICE This email and any attachments are strictly confidential and subject to copyright. They may contain privileged information. If you are not the intended recipient please delete the message and notify the sender. You should not read, copy, use, change, alter or disclose this email or its attachments without authorisation. The company and any related or associated companies do not accept any liability in connection with this email and any attachments including in connection with computer viruses, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Any views expressed in this email and any attachments do not necessarily reflect the views of the company or the views of any of our related or associated companies. ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2963 bytes Desc: image001.jpg URL: From bluethundr at gmail.com Sat May 10 04:58:08 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Sat, 10 May 2014 00:58:08 -0400 Subject: web backend is sick Message-ID: Hey all, I have two web backends in my varnish config. And one node is reporting healthy and the other is being reported as 'sick'. 10 Backend c 11 www web1 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001130 0.001067 HTTP/1.1 200 OK 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001231 0.001108 HTTP/1.1 200 OK 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001250 0.001143 HTTP/1.1 200 OK 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001127 0.001139 HTTP/1.1 200 OK 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001208 0.001157 HTTP/1.1 200 OK 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001562 0.001258 HTTP/1.1 200 OK 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001545 0.001330 HTTP/1.1 200 OK 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001363 0.001338 HTTP/1.1 200 OK 11 BackendClose b web1 [root at varnish1:/etc/varnish] #varnishlog | grep web2 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 And I'm really at a loss to understand why. Both nodes should be completely identical. And the web roots on both are basically svn repos that are in sync. >From web1 : [root at beta:/var/www/jf-current] #svn info | grep -i revision Revision: 17 To web2: [root at beta-new:/var/www/jf-current] #svn info | grep -i revision Revision: 17 This is the part of my vcl file where I define the web back ends: probe favicon { .url = "/favicon.ico"; .timeout = 60ms; .interval = 2s; .window = 5; .threshold = 3; } backend web1 { .host = "xx.xx.xx.xx"; .port = "80"; .probe = favicon; } backend web2 { .host = "xx.xx.xx.xx"; .port = "80"; .probe = favicon; } And the file that varnish is probing for is present on both: [root at beta:/var/www/jf-current] #ls -l /var/www/jf-current/favicon.ico -rwxrwxr-x 1 apache ftp 1150 Dec 22 00:53 /var/www/jf-current/favicon.ico I've also setup individual web URLs for each host that isn't cached in varnish so I can hit each one. And each site comes up ok. So I'm a little puzzled as to why the second web host is reporting 'sick' and what I can do to get it back into load balancing. Thanks for any help you can provide! Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluethundr at gmail.com Sun May 11 22:20:50 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Sun, 11 May 2014 18:20:50 -0400 Subject: site goes down if same one of two varnish nodes stopped Message-ID: hey all.. I have two varnish nodes being balanced by an F5 load balancer both were installed in the same exact manner with yum installing local rpms of varnish 2.1.5 (the requested version of the client). Both share the exact same default.vcl file. But if you take node a down with node b running the whole site goes down if you take node b down with node a running the site stays up. I need to determine why node b isn't supporting the site. Each varnish node needs to be balancing 3 web servers and it looks like the a node does. Since the site goes down when you take down node a and leave node b running I had a look at varnishlog for both and both nodes appear to be getting hit. Node A: 3 VCL_return c deliver 3 TxProtocol c HTTP/1.1 3 TxStatus c 200 3 TxResponse c OK 3 TxHeader c Server: Apache 3 TxHeader c X-Powered-By: PHP/5.2.8 3 TxHeader c Content-Type: text/html 3 TxHeader c Cache-Control: max-age = 600 3 TxHeader c Content-Length: 4 3 TxHeader c Date: Sun, 11 May 2014 22:11:02 GMT 3 TxHeader c X-Varnish: 1578371599 1578371564 3 TxHeader c Age: 86 3 TxHeader c Via: 1.1 varnish 3 TxHeader c Connection: close 3 TxHeader c Varnish-X-Cache: HIT 3 TxHeader c Varnish-X-Cache-Hits: 35 3 Length c 4 3 ReqEnd c 1578371599 1399846262.156239033 1399846262.156332970 0.000054121 0.000056028 0.000037909 Node B: 9 VCL_return c deliver 9 TxProtocol c HTTP/1.1 9 TxStatus c 200 9 TxResponse c OK 9 TxHeader c Server: Apache 9 TxHeader c X-Powered-By: PHP/5.2.17 9 TxHeader c Content-Type: text/html 9 TxHeader c Cache-Control: max-age = 600 9 TxHeader c Content-Length: 4 9 TxHeader c Date: Sun, 11 May 2014 22:11:33 GMT 9 TxHeader c X-Varnish: 1525629213 1525629076 9 TxHeader c Age: 341 9 TxHeader c Via: 1.1 varnish 9 TxHeader c Connection: close 9 TxHeader c Varnish-X-Cache: HIT 9 TxHeader c Varnish-X-Cache-Hits: 137 9 Length c 4 9 ReqEnd c 1525629213 1399846293.098695993 1399846293.098922968 0.000057936 0.000181913 0.000045061 So I'm not sure why this is the case. Here?s the VCL file that I?m using in case this might shed any clues. I apologize that I?m still to much of a newb to ferret out the most relevant parts. But I hope that the context may yield some clues. backend web1 { .host = "10.10.1.104"; .port = "80"; .connect_timeout = 45s; .first_byte_timeout = 45s; .between_bytes_timeout = 45s; .max_connections = 70; .probe = { .url = "/healthcheck.php"; .timeout = 5s; .interval = 30s; .window = 10; .threshold = 1; } } backend web2 { .host = "10.10.1.105"; .port = "80"; .connect_timeout = 45s; .first_byte_timeout = 45s; .between_bytes_timeout = 45s; .max_connections = 70; .probe = { .url = "/healthcheck.php"; .timeout = 5s; .interval = 30s; .window = 10; .threshold = 1; } } backend web3 { .host = "10.10.1.106"; .port = "80"; .connect_timeout = 45s; .first_byte_timeout = 45s; .between_bytes_timeout = 45s; .max_connections = 70; .probe = { .url = "/healthcheck.php"; .timeout = 5s; .interval = 30s; .window = 10; .threshold = 1; } } acl purge { "localhost"; "127.0.0.1"; "10.10.1.102"; "10.10.1.103"; } director www round-robin { { .backend = web1; } { .backend = web2; } { .backend = web3; } } sub vcl_recv { set req.backend = www; set req.grace = 6h; if (!req.backend.healthy) { set req.grace = 24h; } set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " client.ip; if (req.http.host ~ "^origin\.test(.+\.|)mywebsite\.com$") { return (pass); } if (req.http.host ~ ".*\.mywebsite.com|mywebsite.com") { /* allow (origin.)stage.m.mywebsite.com to be a separate host */ if (req.http.host != "stage.m.mywebsite.com") { set req.http.host = "stage.mywebsite.com"; } } else { return (pass); } if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } return (lookup); } if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { return (pipe); } if (req.request != "GET" && req.request != "HEAD") { return (pass); } if (req.url ~ "sites/all/modules/custom/bravo_ad/ads.html\?.*") { set req.url = "/sites/all/modules/custom/bravo_ad/ads.html"; } if (req.url ~ "eyeblaster/addineyeV2.html\?.*") { set req.url = "/eyeblaster/addineyeV2.html"; } if (req.url ~ "ahah_helper\.php|bravo_points\.php|install\.php|update\.php|cron\.php|/json(:?\?.*)?$") { return (pass); } if (req.http.Authorization) { return (pass); } if (req.url ~ "login" || req.url ~ "logout") { return (pass); } if (req.url ~ "^/admin/" || req.url ~ "^/node/add/") { return (pass); } if (req.http.Cache-Control ~ "no-cache") { // return (pass); } if (req.http.Cookie ~ "(VARNISH|DRUPAL_UID|LOGGED_IN|SESS|_twitter_sess)") { set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", ""); set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); } else { unset req.http.Cookie; } /* removed varnish cache backend logic */ if (req.restarts == 0) { set req.backend = www; } elsif (req.restarts >= 2) { return (pass); } if (req.restarts >= 2) { return (pass); } if (req.url ~ "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") { unset req.http.Accept-Encoding; } if (req.url ~ "^/(sites/all/modules/mywebsite_admanager/includes/ads.php|doubleclick/DARTIframe.html)(\?.*|)$") { set req.url = regsub(req.url, "\?.*$", ""); } if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { unset req.http.Accept-Encoding; } return (lookup); } sub vcl_pipe { set bereq.http.connection = "close"; return (pipe); } sub vcl_pass { return (pass); } sub vcl_hash { set req.hash += req.url; set req.hash += req.http.host; if (req.http.Cookie ~ "VARNISH|DRUPAL_UID|LOGGED_IN") { set req.hash += req.http.Cookie; } return (hash); } sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged."; } } sub vcl_fetch { if (beresp.status == 500) { set req.http.X-Varnish-Error = "1"; restart; } set beresp.grace = 6h; # Set a short circuit cache lifetime for resp codes above 302 if (beresp.status > 302) { set beresp.ttl = 60s; set beresp.http.Cache-Control = "max-age = 60"; } if (beresp.http.Edge-control ~ "no-store") { set beresp.http.storage = "1"; set beresp.cacheable = false; return (pass); } if (beresp.status >= 300 || !beresp.cacheable) { set beresp.http.Varnish-X-Cacheable = "Not Cacheable"; set beresp.http.storage = "1"; return (pass); } if (beresp.http.Set-Cookie) { return (pass); } if (beresp.cacheable) { unset beresp.http.expires; set beresp.ttl = 600s; set beresp.http.Cache-Control = "max-age = 600"; if (req.url ~ "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") { set beresp.ttl = 43829m; set beresp.http.Cache-Control = "max-age = 1000000"; } } return (deliver); } sub vcl_deliver { if (obj.hits > 0) { set resp.http.Varnish-X-Cache = "HIT"; set resp.http.Varnish-X-Cache-Hits = obj.hits; } else { set resp.http.Varnish-X-Cache = "MISS"; } return (deliver); } sub vcl_error { if (req.restarts == 0) { return (restart); } if (req.http.X-Varnish-Error != "1") { set req.http.X-Varnish-Error = "1"; return (restart); } } The only part that I omitted was the one pointing to the error page. Can anyone offer any advice on how to troubleshoot this? I'm enclosing the full VCL in case that extra info is helpful. I didn't omit much tho. Thank you! Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: default.vcl-node-a-stage Type: application/octet-stream Size: 7209 bytes Desc: not available URL: From bluethundr at gmail.com Sun May 11 23:15:13 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Sun, 11 May 2014 19:15:13 -0400 Subject: site goes down if same one of two varnish nodes stopped In-Reply-To: References: Message-ID: Hey guys, One more interesting thing about my situation. Is that if I do a varnishstat command on both node A (which seems to control the site) and node B (which does not seem to), I get further evidence that both nodes are supporting the site. 0+02:10:12 *uszmpwsls014la* Hitrate ratio: 4 4 4 Hitrate avg: 0.9977 0.9977 0.9977 3139 1.00 0.40 Client connections accepted 3149 1.00 0.40 Client requests received 3120 1.00 0.40 Cache hits 29 0.00 0.00 Cache misses 25 0.00 0.00 Backend conn. success 4 0.00 0.00 Backend conn. reuses 20 0.00 0.00 Backend conn. was closed 26 0.00 0.00 Backend conn. recycles 29 0.00 0.00 Fetch with Length 16 . . N struct sess_mem 26 . . N struct object 36 . . N struct objectcore 25 . . N struct objecthead 2 . . N struct vbe_conn 500 . . N worker threads 500 0.00 0.06 N worker threads created 3 . . N backends 1563 . . N LRU moved objects 3128 1.00 0.40 Objects sent with write 3139 1.00 0.40 Total Sessions 0+03:04:56 *uszmpwsls014lb* Hitrate ratio: 10 21 21 Hitrate avg: 0.9999 0.9998 0.9998 4440 2.00 0.40 Client connections accepted 4440 2.00 0.40 Client requests received 4421 2.00 0.40 Cache hits 19 0.00 0.00 Cache misses 19 0.00 0.00 Backend conn. success 16 0.00 0.00 Backend conn. was closed 19 0.00 0.00 Backend conn. recycles 19 0.00 0.00 Fetch with Length 10 . . N struct sess_mem 19 . . N struct object 29 . . N struct objectcore 11 . . N struct objecthead 3 . . N struct vbe_conn 500 . . N worker threads 500 0.00 0.05 N worker threads created 3 . . N backends 2209 . . N LRU moved objects 4440 2.00 0.40 Objects sent with write 4440 2.00 0.40 Total Sessions 4440 2.00 0.40 Total Requests So why the entire site goes down when I bring down node A but leave up node B I am still a little puzzled by. Unless the explanation may be that the F5 is NOT balancing the two varnish nodes in quite the way I appear to think. But if that is the case, then why do we see almost identical stats coming out of both hosts? Thanks Tim On Sun, May 11, 2014 at 6:20 PM, Tim Dunphy wrote: > hey all.. > > I have two varnish nodes being balanced by an F5 load balancer both were > installed in the same exact manner with yum installing local rpms of > varnish 2.1.5 (the requested version of the client). > > Both share the exact same default.vcl file. But if you take node a down > with node b running the whole site goes down if you take node b down with > node a running the site stays up. I need to determine why node b isn't > supporting the site. Each varnish node needs to be balancing 3 web servers > and it looks like the a node does. Since the site goes down when you take > down node a and leave node b running > > I had a look at varnishlog for both and both nodes appear to be getting > hit. > > Node A: > > 3 VCL_return c deliver > > 3 TxProtocol c HTTP/1.1 > > 3 TxStatus c 200 > > 3 TxResponse c OK > > 3 TxHeader c Server: Apache > > 3 TxHeader c X-Powered-By: PHP/5.2.8 > > 3 TxHeader c Content-Type: text/html > > 3 TxHeader c Cache-Control: max-age = 600 > > 3 TxHeader c Content-Length: 4 > > 3 TxHeader c Date: Sun, 11 May 2014 22:11:02 GMT > > 3 TxHeader c X-Varnish: 1578371599 1578371564 > > 3 TxHeader c Age: 86 > > 3 TxHeader c Via: 1.1 varnish > > 3 TxHeader c Connection: close > > 3 TxHeader c Varnish-X-Cache: HIT > > 3 TxHeader c Varnish-X-Cache-Hits: 35 > > 3 Length c 4 > > 3 ReqEnd c 1578371599 1399846262.156239033 1399846262.156332970 > 0.000054121 0.000056028 0.000037909 > > > Node B: > > 9 VCL_return c deliver > > 9 TxProtocol c HTTP/1.1 > > 9 TxStatus c 200 > > 9 TxResponse c OK > > 9 TxHeader c Server: Apache > > 9 TxHeader c X-Powered-By: PHP/5.2.17 > > 9 TxHeader c Content-Type: text/html > > 9 TxHeader c Cache-Control: max-age = 600 > > 9 TxHeader c Content-Length: 4 > > 9 TxHeader c Date: Sun, 11 May 2014 22:11:33 GMT > > 9 TxHeader c X-Varnish: 1525629213 1525629076 > > 9 TxHeader c Age: 341 > > 9 TxHeader c Via: 1.1 varnish > > 9 TxHeader c Connection: close > > 9 TxHeader c Varnish-X-Cache: HIT > > 9 TxHeader c Varnish-X-Cache-Hits: 137 > > 9 Length c 4 > > 9 ReqEnd c 1525629213 1399846293.098695993 1399846293.098922968 > 0.000057936 0.000181913 0.000045061 > > So I'm not sure why this is the case. > > Here?s the VCL file that I?m using in case this might shed any clues. I > apologize that I?m still to much of a newb to ferret out the most relevant > parts. But I hope that the context may yield some clues. > > backend web1 { > > .host = "10.10.1.104"; > > .port = "80"; > > .connect_timeout = 45s; > > .first_byte_timeout = 45s; > > .between_bytes_timeout = 45s; > > .max_connections = 70; > > .probe = { > > .url = "/healthcheck.php"; > > .timeout = 5s; > > .interval = 30s; > > .window = 10; > > .threshold = 1; > > } > > } > > backend web2 { > > .host = "10.10.1.105"; > > .port = "80"; > > .connect_timeout = 45s; > > .first_byte_timeout = 45s; > > .between_bytes_timeout = 45s; > > .max_connections = 70; > > .probe = { > > .url = "/healthcheck.php"; > > .timeout = 5s; > > .interval = 30s; > > .window = 10; > > .threshold = 1; > > } > > } > > backend web3 { > > .host = "10.10.1.106"; > > .port = "80"; > > .connect_timeout = 45s; > > .first_byte_timeout = 45s; > > .between_bytes_timeout = 45s; > > .max_connections = 70; > > .probe = { > > .url = "/healthcheck.php"; > > .timeout = 5s; > > .interval = 30s; > > .window = 10; > > .threshold = 1; > > } > > } > > acl purge { > > "localhost"; > > "127.0.0.1"; > > "10.10.1.102"; > > "10.10.1.103"; > > } > > director www round-robin { > > { .backend = web1; } > > { .backend = web2; } > > { .backend = web3; } > > > } > > sub vcl_recv { > > set req.backend = www; > > set req.grace = 6h; > > if (!req.backend.healthy) { > > set req.grace = 24h; > > } > > set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " client.ip; > > if (req.http.host ~ "^origin\.test(.+\.|)mywebsite\.com$") { > > return (pass); > > } > > if (req.http.host ~ ".*\.mywebsite.com|mywebsite.com") { > > /* allow (origin.)stage.m.mywebsite.com to be a separate host */ > > if (req.http.host != "stage.m.mywebsite.com") { > > set req.http.host = "stage.mywebsite.com"; > > } > > } else { > > return (pass); > > } > > if (req.request == "PURGE") { > > if (!client.ip ~ purge) { > > error 405 "Not allowed."; > > } > > return (lookup); > > } > > if (req.request != "GET" && > > req.request != "HEAD" && > > req.request != "PUT" && > > req.request != "POST" && > > req.request != "TRACE" && > > req.request != "OPTIONS" && > > req.request != "DELETE") { > > return (pipe); > > } > > if (req.request != "GET" && req.request != "HEAD") { > > return (pass); > > } > > if (req.url ~ "sites/all/modules/custom/bravo_ad/ads.html\?.*") { > > set req.url = "/sites/all/modules/custom/bravo_ad/ads.html"; > > } > > if (req.url ~ "eyeblaster/addineyeV2.html\?.*") { > > set req.url = "/eyeblaster/addineyeV2.html"; > > } > > if (req.url ~ > "ahah_helper\.php|bravo_points\.php|install\.php|update\.php|cron\.php|/json(:?\?.*)?$") > { > > return (pass); > > } > > if (req.http.Authorization) { > > return (pass); > > } > > if (req.url ~ "login" || req.url ~ "logout") { > > return (pass); > > } > > if (req.url ~ "^/admin/" || req.url ~ "^/node/add/") { > > return (pass); > > } > > if (req.http.Cache-Control ~ "no-cache") { > > // return (pass); > > } > > if (req.http.Cookie ~ > "(VARNISH|DRUPAL_UID|LOGGED_IN|SESS|_twitter_sess)") { > > set req.http.Cookie = regsuball(req.http.Cookie, > "(^|;\s*)(__[a-z]+|has_js)=[^;]*", ""); > > set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); > > } else { > > unset req.http.Cookie; > > } > > /* removed varnish cache backend logic */ > > if (req.restarts == 0) { > > set req.backend = www; > > } elsif (req.restarts >= 2) { > > return (pass); > > } > > if (req.restarts >= 2) { > > return (pass); > > } > > if (req.url ~ > "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") > { > > unset req.http.Accept-Encoding; > > } > > if (req.url ~ > "^/(sites/all/modules/mywebsite_admanager/includes/ads.php|doubleclick/DARTIframe.html)(\?.*|)$") > { > > set req.url = regsub(req.url, "\?.*$", ""); > > } > > if (req.http.Accept-Encoding ~ "gzip") { > > set req.http.Accept-Encoding = "gzip"; > > } elsif (req.http.Accept-Encoding ~ "deflate") { > > set req.http.Accept-Encoding = "deflate"; > > } else { > > unset req.http.Accept-Encoding; > > } > > return (lookup); > > } > > sub vcl_pipe { > > set bereq.http.connection = "close"; > > return (pipe); > > } > > sub vcl_pass { > > return (pass); > > } > > sub vcl_hash { > > set req.hash += req.url; > > set req.hash += req.http.host; > > if (req.http.Cookie ~ "VARNISH|DRUPAL_UID|LOGGED_IN") { > > set req.hash += req.http.Cookie; > > } > > return (hash); > > } > > sub vcl_hit { > > if (req.request == "PURGE") { > > set obj.ttl = 0s; > > error 200 "Purged."; > > } > > } > > sub vcl_fetch { > > if (beresp.status == 500) { > > set req.http.X-Varnish-Error = "1"; > > restart; > > } > > set beresp.grace = 6h; > > # Set a short circuit cache lifetime for resp codes above 302 > > if (beresp.status > 302) { > > set beresp.ttl = 60s; > > set beresp.http.Cache-Control = "max-age = 60"; > > } > > if (beresp.http.Edge-control ~ "no-store") { > > set beresp.http.storage = "1"; > > set beresp.cacheable = false; > > return (pass); > > } > > if (beresp.status >= 300 || !beresp.cacheable) { > > set beresp.http.Varnish-X-Cacheable = "Not Cacheable"; > > set beresp.http.storage = "1"; > > return (pass); > > } > > if (beresp.http.Set-Cookie) { > > return (pass); > > } > > if (beresp.cacheable) { > > unset beresp.http.expires; > > set beresp.ttl = 600s; > > set beresp.http.Cache-Control = "max-age = 600"; > > if (req.url ~ > "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") > { > > set beresp.ttl = 43829m; > > set beresp.http.Cache-Control = "max-age = 1000000"; > > } > > } > > return (deliver); > > } > > > sub vcl_deliver { > > if (obj.hits > 0) { > > set resp.http.Varnish-X-Cache = "HIT"; > > set resp.http.Varnish-X-Cache-Hits = obj.hits; > > } else { > > set resp.http.Varnish-X-Cache = "MISS"; > > } > > return (deliver); > > } > > sub vcl_error { > > if (req.restarts == 0) { > > return (restart); > > } > > if (req.http.X-Varnish-Error != "1") { > > set req.http.X-Varnish-Error = "1"; > > return (restart); > > } > > } > > The only part that I omitted was the one pointing to the error page. Can > anyone offer any advice on how to troubleshoot this? > > I'm enclosing the full VCL in case that extra info is helpful. I didn't > omit much tho. > > Thank you! > > Tim > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdh132 at psu.edu Mon May 12 00:08:36 2014 From: jdh132 at psu.edu (Jason Heffner) Date: Sun, 11 May 2014 20:08:36 -0400 Subject: site goes down if same one of two varnish nodes stopped In-Reply-To: References: Message-ID: <8622E7F3-6DDA-46B1-80FD-4D7A5E1886CC@psu.edu> It sounds like you are using a tcp monitor on your F5 from reading over at first glance. If varnish goes down, but the system stays up, your monitor wouldn?t remove the node from the pool and keeps sending connections to that node. You want to use a custom monitor like in the attached image in combination with this in your vcl. You can test this by stopping one of your varnish nodes and seeing if it is marked down in the pool. // add ping url to test Varnish status if (req.request == "GET" && req.url ~ "/varnish-ping") { error 200 "OK"; } Jason p: (814) 865-1840, c: (814) 777-7665 Systems Administrator Teaching and Learning with Technology, Information Technology Services The Pennsylvania State University On May 11, 2014, at 7:15 PM, Tim Dunphy wrote: > Hey guys, > > One more interesting thing about my situation. Is that if I do a varnishstat command on both node A (which seems to control the site) and node B (which does not seem to), I get further evidence that both nodes are supporting the site. > > > > 0+02:10:12 uszmpwsls014la > > Hitrate ratio: 4 4 4 > > Hitrate avg: 0.9977 0.9977 0.9977 > > > > 3139 1.00 0.40 Client connections accepted > > 3149 1.00 0.40 Client requests received > > 3120 1.00 0.40 Cache hits > > 29 0.00 0.00 Cache misses > > 25 0.00 0.00 Backend conn. success > > 4 0.00 0.00 Backend conn. reuses > > 20 0.00 0.00 Backend conn. was closed > > 26 0.00 0.00 Backend conn. recycles > > 29 0.00 0.00 Fetch with Length > > 16 . . N struct sess_mem > > 26 . . N struct object > > 36 . . N struct objectcore > > 25 . . N struct objecthead > > 2 . . N struct vbe_conn > > 500 . . N worker threads > > 500 0.00 0.06 N worker threads created > > 3 . . N backends > > 1563 . . N LRU moved objects > > 3128 1.00 0.40 Objects sent with write > > 3139 1.00 0.40 Total Sessions > > > > 0+03:04:56 uszmpwsls014lb > > Hitrate ratio: 10 21 21 > > Hitrate avg: 0.9999 0.9998 0.9998 > > > > 4440 2.00 0.40 Client connections accepted > > 4440 2.00 0.40 Client requests received > > 4421 2.00 0.40 Cache hits > > 19 0.00 0.00 Cache misses > > 19 0.00 0.00 Backend conn. success > > 16 0.00 0.00 Backend conn. was closed > > 19 0.00 0.00 Backend conn. recycles > > 19 0.00 0.00 Fetch with Length > > 10 . . N struct sess_mem > > 19 . . N struct object > > 29 . . N struct objectcore > > 11 . . N struct objecthead > > 3 . . N struct vbe_conn > > 500 . . N worker threads > > 500 0.00 0.05 N worker threads created > > 3 . . N backends > > 2209 . . N LRU moved objects > > 4440 2.00 0.40 Objects sent with write > > 4440 2.00 0.40 Total Sessions > > 4440 2.00 0.40 Total Requests > > So why the entire site goes down when I bring down node A but leave up node B I am still a little puzzled by. Unless the explanation may be that the F5 is NOT balancing the two varnish nodes in quite the way I appear to think. But if that is the case, then why do we see almost identical stats coming out of both hosts? > > > > Thanks > > Tim > > > > On Sun, May 11, 2014 at 6:20 PM, Tim Dunphy wrote: > hey all.. > > I have two varnish nodes being balanced by an F5 load balancer both were installed in the same exact manner with yum installing local rpms of varnish 2.1.5 (the requested version of the client). > Both share the exact same default.vcl file. But if you take node a down with node b running the whole site goes down if you take node b down with node a running the site stays up. I need to determine why node b isn't supporting the site. Each varnish node needs to be balancing 3 web servers and it looks like the a node does. Since the site goes down when you take down node a and leave node b running > I had a look at varnishlog for both and both nodes appear to be getting hit. > > Node A: > > 3 VCL_return c deliver > > 3 TxProtocol c HTTP/1.1 > > 3 TxStatus c 200 > > 3 TxResponse c OK > > 3 TxHeader c Server: Apache > > 3 TxHeader c X-Powered-By: PHP/5.2.8 > > 3 TxHeader c Content-Type: text/html > > 3 TxHeader c Cache-Control: max-age = 600 > > 3 TxHeader c Content-Length: 4 > > 3 TxHeader c Date: Sun, 11 May 2014 22:11:02 GMT > > 3 TxHeader c X-Varnish: 1578371599 1578371564 > > 3 TxHeader c Age: 86 > > 3 TxHeader c Via: 1.1 varnish > > 3 TxHeader c Connection: close > > 3 TxHeader c Varnish-X-Cache: HIT > > 3 TxHeader c Varnish-X-Cache-Hits: 35 > > 3 Length c 4 > > 3 ReqEnd c 1578371599 1399846262.156239033 1399846262.156332970 0.000054121 0.000056028 0.000037909 > > > > Node B: > > 9 VCL_return c deliver > > 9 TxProtocol c HTTP/1.1 > > 9 TxStatus c 200 > > 9 TxResponse c OK > > 9 TxHeader c Server: Apache > > 9 TxHeader c X-Powered-By: PHP/5.2.17 > > 9 TxHeader c Content-Type: text/html > > 9 TxHeader c Cache-Control: max-age = 600 > > 9 TxHeader c Content-Length: 4 > > 9 TxHeader c Date: Sun, 11 May 2014 22:11:33 GMT > > 9 TxHeader c X-Varnish: 1525629213 1525629076 > > 9 TxHeader c Age: 341 > > 9 TxHeader c Via: 1.1 varnish > > 9 TxHeader c Connection: close > > 9 TxHeader c Varnish-X-Cache: HIT > > 9 TxHeader c Varnish-X-Cache-Hits: 137 > > 9 Length c 4 > > 9 ReqEnd c 1525629213 1399846293.098695993 1399846293.098922968 0.000057936 0.000181913 0.000045061 > > So I'm not sure why this is the case. > > Here?s the VCL file that I?m using in case this might shed any clues. I apologize that I?m still to much of a newb to ferret out the most relevant parts. But I hope that the context may yield some clues. > backend web1 { > > .host = "10.10.1.104"; > > .port = "80"; > > .connect_timeout = 45s; > > .first_byte_timeout = 45s; > > .between_bytes_timeout = 45s; > > .max_connections = 70; > > .probe = { > > .url = "/healthcheck.php"; > > .timeout = 5s; > > .interval = 30s; > > .window = 10; > > .threshold = 1; > > } > > } > > backend web2 { > > .host = "10.10.1.105"; > > .port = "80"; > > .connect_timeout = 45s; > > .first_byte_timeout = 45s; > > .between_bytes_timeout = 45s; > > .max_connections = 70; > > .probe = { > > .url = "/healthcheck.php"; > > .timeout = 5s; > > .interval = 30s; > > .window = 10; > > .threshold = 1; > > } > > } > > backend web3 { > > .host = "10.10.1.106"; > > .port = "80"; > > .connect_timeout = 45s; > > .first_byte_timeout = 45s; > > .between_bytes_timeout = 45s; > > .max_connections = 70; > > .probe = { > > .url = "/healthcheck.php"; > > .timeout = 5s; > > .interval = 30s; > > .window = 10; > > .threshold = 1; > > } > > } > > acl purge { > > "localhost"; > > "127.0.0.1"; > > "10.10.1.102"; > > "10.10.1.103"; > > } > > director www round-robin { > > { .backend = web1; } > > { .backend = web2; } > > { .backend = web3; } > > > > } > > sub vcl_recv { > > set req.backend = www; > > set req.grace = 6h; > > if (!req.backend.healthy) { > > set req.grace = 24h; > > } > > set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " client.ip; > > if (req.http.host ~ "^origin\.test(.+\.|)mywebsite\.com$") { > > return (pass); > > } > > if (req.http.host ~ ".*\.mywebsite.com|mywebsite.com") { > > /* allow (origin.)stage.m.mywebsite.com to be a separate host */ > > if (req.http.host != "stage.m.mywebsite.com") { > > set req.http.host = "stage.mywebsite.com"; > > } > > } else { > > return (pass); > > } > > if (req.request == "PURGE") { > > if (!client.ip ~ purge) { > > error 405 "Not allowed."; > > } > > return (lookup); > > } > > if (req.request != "GET" && > > req.request != "HEAD" && > > req.request != "PUT" && > > req.request != "POST" && > > req.request != "TRACE" && > > req.request != "OPTIONS" && > > req.request != "DELETE") { > > return (pipe); > > } > > if (req.request != "GET" && req.request != "HEAD") { > > return (pass); > > } > > if (req.url ~ "sites/all/modules/custom/bravo_ad/ads.html\?.*") { > > set req.url = "/sites/all/modules/custom/bravo_ad/ads.html"; > > } > > if (req.url ~ "eyeblaster/addineyeV2.html\?.*") { > > set req.url = "/eyeblaster/addineyeV2.html"; > > } > > if (req.url ~ "ahah_helper\.php|bravo_points\.php|install\.php|update\.php|cron\.php|/json(:?\?.*)?$") { > > return (pass); > > } > > if (req.http.Authorization) { > > return (pass); > > } > > if (req.url ~ "login" || req.url ~ "logout") { > > return (pass); > > } > > if (req.url ~ "^/admin/" || req.url ~ "^/node/add/") { > > return (pass); > > } > > if (req.http.Cache-Control ~ "no-cache") { > > // return (pass); > > } > > if (req.http.Cookie ~ "(VARNISH|DRUPAL_UID|LOGGED_IN|SESS|_twitter_sess)") { > > set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", ""); > > set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); > > } else { > > unset req.http.Cookie; > > } > > /* removed varnish cache backend logic */ > > if (req.restarts == 0) { > > set req.backend = www; > > } elsif (req.restarts >= 2) { > > return (pass); > > } > > if (req.restarts >= 2) { > > return (pass); > > } > > if (req.url ~ "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") { > > unset req.http.Accept-Encoding; > > } > > if (req.url ~ "^/(sites/all/modules/mywebsite_admanager/includes/ads.php|doubleclick/DARTIframe.html)(\?.*|)$") { > > set req.url = regsub(req.url, "\?.*$", ""); > > } > > if (req.http.Accept-Encoding ~ "gzip") { > > set req.http.Accept-Encoding = "gzip"; > > } elsif (req.http.Accept-Encoding ~ "deflate") { > > set req.http.Accept-Encoding = "deflate"; > > } else { > > unset req.http.Accept-Encoding; > > } > > return (lookup); > > } > > sub vcl_pipe { > > set bereq.http.connection = "close"; > > return (pipe); > > } > > sub vcl_pass { > > return (pass); > > } > > sub vcl_hash { > > set req.hash += req.url; > > set req.hash += req.http.host; > > if (req.http.Cookie ~ "VARNISH|DRUPAL_UID|LOGGED_IN") { > > set req.hash += req.http.Cookie; > > } > > return (hash); > > } > > sub vcl_hit { > > if (req.request == "PURGE") { > > set obj.ttl = 0s; > > error 200 "Purged."; > > } > > } > > sub vcl_fetch { > > if (beresp.status == 500) { > > set req.http.X-Varnish-Error = "1"; > > restart; > > } > > set beresp.grace = 6h; > > # Set a short circuit cache lifetime for resp codes above 302 > > if (beresp.status > 302) { > > set beresp.ttl = 60s; > > set beresp.http.Cache-Control = "max-age = 60"; > > } > > if (beresp.http.Edge-control ~ "no-store") { > > set beresp.http.storage = "1"; > > set beresp.cacheable = false; > > return (pass); > > } > > if (beresp.status >= 300 || !beresp.cacheable) { > > set beresp.http.Varnish-X-Cacheable = "Not Cacheable"; > > set beresp.http.storage = "1"; > > return (pass); > > } > > if (beresp.http.Set-Cookie) { > > return (pass); > > } > > if (beresp.cacheable) { > > unset beresp.http.expires; > > set beresp.ttl = 600s; > > set beresp.http.Cache-Control = "max-age = 600"; > > if (req.url ~ "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") { > > set beresp.ttl = 43829m; > > set beresp.http.Cache-Control = "max-age = 1000000"; > > } > > } > > return (deliver); > > } > > > > sub vcl_deliver { > > if (obj.hits > 0) { > > set resp.http.Varnish-X-Cache = "HIT"; > > set resp.http.Varnish-X-Cache-Hits = obj.hits; > > } else { > > set resp.http.Varnish-X-Cache = "MISS"; > > } > > return (deliver); > > } > > sub vcl_error { > > if (req.restarts == 0) { > > return (restart); > > } > > if (req.http.X-Varnish-Error != "1") { > > set req.http.X-Varnish-Error = "1"; > > return (restart); > > } > > } > > The only part that I omitted was the one pointing to the error page. Can anyone offer any advice on how to troubleshoot this? > > I'm enclosing the full VCL in case that extra info is helpful. I didn't omit much tho. > > Thank you! > > Tim > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: varnish-ping.png Type: image/png Size: 128851 bytes Desc: not available URL: From bluethundr at gmail.com Mon May 12 00:33:29 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Sun, 11 May 2014 20:33:29 -0400 Subject: site goes down if same one of two varnish nodes stopped In-Reply-To: <8622E7F3-6DDA-46B1-80FD-4D7A5E1886CC@psu.edu> References: <8622E7F3-6DDA-46B1-80FD-4D7A5E1886CC@psu.edu> Message-ID: > > It sounds like you are using a tcp monitor on your F5 from reading over at > first glance. If varnish goes down, but the system stays up, your monitor > wouldn?t remove the node from the pool and keeps sending connections to > that node. You want to use a custom monitor like in the attached image in > combination with this in your vcl. You can test this by stopping one of > your varnish nodes and seeing if it is marked down in the pool. > // add ping url to test Varnish status > if (req.request == "GET" && req.url ~ "/varnish-ping") { > error 200 "OK"; > } Hi Jason, Thank you very much for your reply. And yeah, I sort of think this is an issue with the F5 and not with Varnish. Mainly because both Varnish instances are identically installed and configured. I don't actually have direct access to the F5 at work. But one of the F5 guys that I deal with is very easy going and I'm sure will be ready to help. I'll ping him with this scenario tomorrow. Thank you for confirming my suspicion that this issue is likely on the F5 end and not the Varnish end. Thanks Tim On Sun, May 11, 2014 at 8:08 PM, Jason Heffner wrote: > It sounds like you are using a tcp monitor on your F5 from reading over at > first glance. If varnish goes down, but the system stays up, your monitor > wouldn?t remove the node from the pool and keeps sending connections to > that node. You want to use a custom monitor like in the attached image in > combination with this in your vcl. You can test this by stopping one of > your varnish nodes and seeing if it is marked down in the pool. > > // add ping url to test Varnish status > if (req.request == "GET" && req.url ~ "/varnish-ping") { > error 200 "OK"; > } > > > Jason > > p: (814) 865-1840, c: (814) 777-7665 > Systems Administrator > Teaching and Learning with Technology, Information Technology Services > The Pennsylvania State University > > On May 11, 2014, at 7:15 PM, Tim Dunphy wrote: > > Hey guys, > > One more interesting thing about my situation. Is that if I do a > varnishstat command on both node A (which seems to control the site) and > node B (which does not seem to), I get further evidence that both nodes are > supporting the site. > > > 0+02:10:12 > *uszmpwsls014la* > > Hitrate ratio: 4 4 4 > > Hitrate avg: 0.9977 0.9977 0.9977 > > > 3139 1.00 0.40 Client connections accepted > > 3149 1.00 0.40 Client requests received > > 3120 1.00 0.40 Cache hits > > 29 0.00 0.00 Cache misses > > 25 0.00 0.00 Backend conn. success > > 4 0.00 0.00 Backend conn. reuses > > 20 0.00 0.00 Backend conn. was closed > > 26 0.00 0.00 Backend conn. recycles > > 29 0.00 0.00 Fetch with Length > > 16 . . N struct sess_mem > > 26 . . N struct object > > 36 . . N struct objectcore > > 25 . . N struct objecthead > > 2 . . N struct vbe_conn > > 500 . . N worker threads > > 500 0.00 0.06 N worker threads created > > 3 . . N backends > > 1563 . . N LRU moved objects > > 3128 1.00 0.40 Objects sent with write > > 3139 1.00 0.40 Total Sessions > > > 0+03:04:56 > *uszmpwsls014lb* > > Hitrate ratio: 10 21 21 > > Hitrate avg: 0.9999 0.9998 0.9998 > > > 4440 2.00 0.40 Client connections accepted > > 4440 2.00 0.40 Client requests received > > 4421 2.00 0.40 Cache hits > > 19 0.00 0.00 Cache misses > > 19 0.00 0.00 Backend conn. success > > 16 0.00 0.00 Backend conn. was closed > > 19 0.00 0.00 Backend conn. recycles > > 19 0.00 0.00 Fetch with Length > > 10 . . N struct sess_mem > > 19 . . N struct object > > 29 . . N struct objectcore > > 11 . . N struct objecthead > > 3 . . N struct vbe_conn > > 500 . . N worker threads > > 500 0.00 0.05 N worker threads created > > 3 . . N backends > > 2209 . . N LRU moved objects > > 4440 2.00 0.40 Objects sent with write > > 4440 2.00 0.40 Total Sessions > > 4440 2.00 0.40 Total Requests > > So why the entire site goes down when I bring down node A but leave up > node B I am still a little puzzled by. Unless the explanation may be that > the F5 is NOT balancing the two varnish nodes in quite the way I appear to > think. But if that is the case, then why do we see almost identical stats > coming out of both hosts? > > > Thanks > > Tim > > > On Sun, May 11, 2014 at 6:20 PM, Tim Dunphy wrote: > >> hey all.. >> >> I have two varnish nodes being balanced by an F5 load balancer both were >> installed in the same exact manner with yum installing local rpms of >> varnish 2.1.5 (the requested version of the client). >> >> Both share the exact same default.vcl file. But if you take node a down >> with node b running the whole site goes down if you take node b down with >> node a running the site stays up. I need to determine why node b isn't >> supporting the site. Each varnish node needs to be balancing 3 web servers >> and it looks like the a node does. Since the site goes down when you take >> down node a and leave node b running >> >> I had a look at varnishlog for both and both nodes appear to be getting >> hit. >> >> Node A: >> >> 3 VCL_return c deliver >> >> 3 TxProtocol c HTTP/1.1 >> >> 3 TxStatus c 200 >> >> 3 TxResponse c OK >> >> 3 TxHeader c Server: Apache >> >> 3 TxHeader c X-Powered-By: PHP/5.2.8 >> >> 3 TxHeader c Content-Type: text/html >> >> 3 TxHeader c Cache-Control: max-age = 600 >> >> 3 TxHeader c Content-Length: 4 >> >> 3 TxHeader c Date: Sun, 11 May 2014 22:11:02 GMT >> >> 3 TxHeader c X-Varnish: 1578371599 1578371564 >> >> 3 TxHeader c Age: 86 >> >> 3 TxHeader c Via: 1.1 varnish >> >> 3 TxHeader c Connection: close >> >> 3 TxHeader c Varnish-X-Cache: HIT >> >> 3 TxHeader c Varnish-X-Cache-Hits: 35 >> >> 3 Length c 4 >> >> 3 ReqEnd c 1578371599 1399846262.156239033 1399846262.156332970 >> 0.000054121 0.000056028 0.000037909 >> >> >> Node B: >> >> 9 VCL_return c deliver >> >> 9 TxProtocol c HTTP/1.1 >> >> 9 TxStatus c 200 >> >> 9 TxResponse c OK >> >> 9 TxHeader c Server: Apache >> >> 9 TxHeader c X-Powered-By: PHP/5.2.17 >> >> 9 TxHeader c Content-Type: text/html >> >> 9 TxHeader c Cache-Control: max-age = 600 >> >> 9 TxHeader c Content-Length: 4 >> >> 9 TxHeader c Date: Sun, 11 May 2014 22:11:33 GMT >> >> 9 TxHeader c X-Varnish: 1525629213 1525629076 >> >> 9 TxHeader c Age: 341 >> >> 9 TxHeader c Via: 1.1 varnish >> >> 9 TxHeader c Connection: close >> >> 9 TxHeader c Varnish-X-Cache: HIT >> >> 9 TxHeader c Varnish-X-Cache-Hits: 137 >> >> 9 Length c 4 >> >> 9 ReqEnd c 1525629213 1399846293.098695993 1399846293.098922968 >> 0.000057936 0.000181913 0.000045061 >> >> So I'm not sure why this is the case. >> >> Here?s the VCL file that I?m using in case this might shed any clues. I >> apologize that I?m still to much of a newb to ferret out the most relevant >> parts. But I hope that the context may yield some clues. >> >> backend web1 { >> >> .host = "10.10.1.104"; >> >> .port = "80"; >> >> .connect_timeout = 45s; >> >> .first_byte_timeout = 45s; >> >> .between_bytes_timeout = 45s; >> >> .max_connections = 70; >> >> .probe = { >> >> .url = "/healthcheck.php"; >> >> .timeout = 5s; >> >> .interval = 30s; >> >> .window = 10; >> >> .threshold = 1; >> >> } >> >> } >> >> backend web2 { >> >> .host = "10.10.1.105"; >> >> .port = "80"; >> >> .connect_timeout = 45s; >> >> .first_byte_timeout = 45s; >> >> .between_bytes_timeout = 45s; >> >> .max_connections = 70; >> >> .probe = { >> >> .url = "/healthcheck.php"; >> >> .timeout = 5s; >> >> .interval = 30s; >> >> .window = 10; >> >> .threshold = 1; >> >> } >> >> } >> >> backend web3 { >> >> .host = "10.10.1.106"; >> >> .port = "80"; >> >> .connect_timeout = 45s; >> >> .first_byte_timeout = 45s; >> >> .between_bytes_timeout = 45s; >> >> .max_connections = 70; >> >> .probe = { >> >> .url = "/healthcheck.php"; >> >> .timeout = 5s; >> >> .interval = 30s; >> >> .window = 10; >> >> .threshold = 1; >> >> } >> >> } >> >> acl purge { >> >> "localhost"; >> >> "127.0.0.1"; >> >> "10.10.1.102"; >> >> "10.10.1.103"; >> >> } >> >> director www round-robin { >> >> { .backend = web1; } >> >> { .backend = web2; } >> >> { .backend = web3; } >> >> >> } >> >> sub vcl_recv { >> >> set req.backend = www; >> >> set req.grace = 6h; >> >> if (!req.backend.healthy) { >> >> set req.grace = 24h; >> >> } >> >> set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " >> client.ip; >> >> if (req.http.host ~ "^origin\.test(.+\.|)mywebsite\.com$") { >> >> return (pass); >> >> } >> >> if (req.http.host ~ ".*\.mywebsite.com|mywebsite.com") { >> >> /* allow (origin.)stage.m.mywebsite.com to be a separate host */ >> >> if (req.http.host != "stage.m.mywebsite.com") { >> >> set req.http.host = "stage.mywebsite.com"; >> >> } >> >> } else { >> >> return (pass); >> >> } >> >> if (req.request == "PURGE") { >> >> if (!client.ip ~ purge) { >> >> error 405 "Not allowed."; >> >> } >> >> return (lookup); >> >> } >> >> if (req.request != "GET" && >> >> req.request != "HEAD" && >> >> req.request != "PUT" && >> >> req.request != "POST" && >> >> req.request != "TRACE" && >> >> req.request != "OPTIONS" && >> >> req.request != "DELETE") { >> >> return (pipe); >> >> } >> >> if (req.request != "GET" && req.request != "HEAD") { >> >> return (pass); >> >> } >> >> if (req.url ~ "sites/all/modules/custom/bravo_ad/ads.html\?.*") { >> >> set req.url = "/sites/all/modules/custom/bravo_ad/ads.html"; >> >> } >> >> if (req.url ~ "eyeblaster/addineyeV2.html\?.*") { >> >> set req.url = "/eyeblaster/addineyeV2.html"; >> >> } >> >> if (req.url ~ >> "ahah_helper\.php|bravo_points\.php|install\.php|update\.php|cron\.php|/json(:?\?.*)?$") >> { >> >> return (pass); >> >> } >> >> if (req.http.Authorization) { >> >> return (pass); >> >> } >> >> if (req.url ~ "login" || req.url ~ "logout") { >> >> return (pass); >> >> } >> >> if (req.url ~ "^/admin/" || req.url ~ "^/node/add/") { >> >> return (pass); >> >> } >> >> if (req.http.Cache-Control ~ "no-cache") { >> >> // return (pass); >> >> } >> >> if (req.http.Cookie ~ >> "(VARNISH|DRUPAL_UID|LOGGED_IN|SESS|_twitter_sess)") { >> >> set req.http.Cookie = regsuball(req.http.Cookie, >> "(^|;\s*)(__[a-z]+|has_js)=[^;]*", ""); >> >> set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); >> >> } else { >> >> unset req.http.Cookie; >> >> } >> >> /* removed varnish cache backend logic */ >> >> if (req.restarts == 0) { >> >> set req.backend = www; >> >> } elsif (req.restarts >= 2) { >> >> return (pass); >> >> } >> >> if (req.restarts >= 2) { >> >> return (pass); >> >> } >> >> if (req.url ~ >> "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") >> { >> >> unset req.http.Accept-Encoding; >> >> } >> >> if (req.url ~ >> "^/(sites/all/modules/mywebsite_admanager/includes/ads.php|doubleclick/DARTIframe.html)(\?.*|)$") >> { >> >> set req.url = regsub(req.url, "\?.*$", ""); >> >> } >> >> if (req.http.Accept-Encoding ~ "gzip") { >> >> set req.http.Accept-Encoding = "gzip"; >> >> } elsif (req.http.Accept-Encoding ~ "deflate") { >> >> set req.http.Accept-Encoding = "deflate"; >> >> } else { >> >> unset req.http.Accept-Encoding; >> >> } >> >> return (lookup); >> >> } >> >> sub vcl_pipe { >> >> set bereq.http.connection = "close"; >> >> return (pipe); >> >> } >> >> sub vcl_pass { >> >> return (pass); >> >> } >> >> sub vcl_hash { >> >> set req.hash += req.url; >> >> set req.hash += req.http.host; >> >> if (req.http.Cookie ~ "VARNISH|DRUPAL_UID|LOGGED_IN") { >> >> set req.hash += req.http.Cookie; >> >> } >> >> return (hash); >> >> } >> >> sub vcl_hit { >> >> if (req.request == "PURGE") { >> >> set obj.ttl = 0s; >> >> error 200 "Purged."; >> >> } >> >> } >> >> sub vcl_fetch { >> >> if (beresp.status == 500) { >> >> set req.http.X-Varnish-Error = "1"; >> >> restart; >> >> } >> >> set beresp.grace = 6h; >> >> # Set a short circuit cache lifetime for resp codes above 302 >> >> if (beresp.status > 302) { >> >> set beresp.ttl = 60s; >> >> set beresp.http.Cache-Control = "max-age = 60"; >> >> } >> >> if (beresp.http.Edge-control ~ "no-store") { >> >> set beresp.http.storage = "1"; >> >> set beresp.cacheable = false; >> >> return (pass); >> >> } >> >> if (beresp.status >= 300 || !beresp.cacheable) { >> >> set beresp.http.Varnish-X-Cacheable = "Not Cacheable"; >> >> set beresp.http.storage = "1"; >> >> return (pass); >> >> } >> >> if (beresp.http.Set-Cookie) { >> >> return (pass); >> >> } >> >> if (beresp.cacheable) { >> >> unset beresp.http.expires; >> >> set beresp.ttl = 600s; >> >> set beresp.http.Cache-Control = "max-age = 600"; >> >> if (req.url ~ >> "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") >> { >> >> set beresp.ttl = 43829m; >> >> set beresp.http.Cache-Control = "max-age = 1000000"; >> >> } >> >> } >> >> return (deliver); >> >> } >> >> >> sub vcl_deliver { >> >> if (obj.hits > 0) { >> >> set resp.http.Varnish-X-Cache = "HIT"; >> >> set resp.http.Varnish-X-Cache-Hits = obj.hits; >> >> } else { >> >> set resp.http.Varnish-X-Cache = "MISS"; >> >> } >> >> return (deliver); >> >> } >> >> sub vcl_error { >> >> if (req.restarts == 0) { >> >> return (restart); >> >> } >> >> if (req.http.X-Varnish-Error != "1") { >> >> set req.http.X-Varnish-Error = "1"; >> >> return (restart); >> >> } >> >> } >> >> The only part that I omitted was the one pointing to the error page. Can >> anyone offer any advice on how to troubleshoot this? >> >> I'm enclosing the full VCL in case that extra info is helpful. I didn't >> omit much tho. >> >> Thank you! >> >> Tim >> >> -- >> GPG me!! >> >> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B >> >> > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: varnish-ping.png Type: image/png Size: 128851 bytes Desc: not available URL: From bluethundr at gmail.com Mon May 12 00:57:34 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Sun, 11 May 2014 20:57:34 -0400 Subject: web backend is sick In-Reply-To: References: Message-ID: I took a look at apache on the host that Varnish reports as sick: And apache seems to be running fine on the 'sick' host: [root at beta:/var/www/jf-current] #apachectl -S VirtualHost configuration: wildcard NameVirtualHosts and _default_ servers: *:443 is a NameVirtualHost default server beta.mywebsite.com(/etc/httpd/conf.d/002_jf_beta_ssl.conf:78) port 443 namevhost beta.mywebsite.com(/etc/httpd/conf.d/002_jf_beta_ssl.conf:78) *:80 is a NameVirtualHost default server ref.mywebsite.com(/etc/httpd/conf.d/001_ref.mywebsite.com.conf:1) port 80 namevhost ref.mywebsite.com(/etc/httpd/conf.d/001_ref.mywebsite.com.conf:1) port 80 namevhost qa.mywebsite.com(/etc/httpd/conf.d/002_qa.mywebsite.com.conf:1) port 80 namevhost beta.mywebsite.com(/etc/httpd/conf.d/003_beta.mywebsite.com.conf:1) port 80 namevhost beta-test.mywebsite.com(/etc/httpd/conf.d/004_beta-test.mywebsite.com.conf:1) port 80 namevhost admin.mywebsite.com(/etc/httpd/conf.d/005_admin.mywebsite.com.conf:1) port 80 namevhost admin.mywebsite.com(/etc/httpd/conf.d/10_admin.mywebsite.com.conf:1) port 80 namevhost beta-test.mywebsite.com(/etc/httpd/conf.d/10_beta-test.mywebsite.com.conf:1) port 80 namevhost beta.mywebsite.com(/etc/httpd/conf.d/10_beta.mywebsite.com.conf:1) port 80 namevhost qa.mywebsite.com(/etc/httpd/conf.d/10_qa.mywebsite.com.conf:1) port 80 namevhost ref.mywebsite.com(/etc/httpd/conf.d/10_ref.mywebsite.com.conf:1) Syntax OK My probe and host definitions in the varnish default.vcl looks like this: probe favicon { .url = "/favicon.ico"; .timeout = 34ms; .interval = 1s; .window = 10; .threshold = 8; } backend web1 { .host = "10.10.1.94"; .port = "80"; .probe = favicon; } backend web2 { .host = "10.10.1.98"; .port = "80"; .probe = favicon; } director www random { { .backend = web1 ; .weight = 2; } { .backend = web2 ; .weight = 2; } } I was just experimenting the load balancing algorithms, but that probably doesn't have much bearing on this problem. >From the varnish host I can do a wget for the probe file from the host that varnish is marking as 'sick' [root at varnish1:/etc/varnish] #wget -O /dev/null -S http://web2.mywebsite.com/favicon.ico --2014-05-11 20:48:23-- http://web1.mywebsite.com/favicon.ico Resolving web1.mywebsite.com... 10.10.1.98 Connecting to web1.mywebsite.com|10.10.1.98|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Mon, 12 May 2014 00:48:25 GMT Server: Apache/2.2.23 (CentOS) Last-Modified: Sun, 22 Dec 2013 00:53:19 GMT ETag: "2a8003-47e-4ee14efeebdc0" Accept-Ranges: bytes Content-Length: 1150 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/plain; charset=UTF-8 Length: 1150 (1.1K) [text/plain] Saving to: ?/dev/null? 100%[================================================================>] 1,150 --.-K/s in 0s 2014-05-11 20:48:24 (144 MB/s) - ?/dev/null? saved [1150/1150] I'm attempting here to approximate the calls that varnish is making to determine if a host is healthy. And yet when I try having a look at debug.health from the command line Vaarnish is still labeling it as 'sick' [root at varnish1:~] #varnishadm -T 127.0.0.1:6082 debug.health -S /etc/varnish/secret *Backend web1 is Healthy* Current states good: 10 threshold: 8 window: 10 Average responsetime of good probes: 0.001247 Oldest Newest ================================================================ 4444444444444444444444444444444444444444444444444444444444444444 Good IPv4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy *Backend web2 is Sick* Current states good: 0 threshold: 8 window: 10 Average responsetime of good probes: 0.000000 Oldest Newest ================================================================ ---------------------------------------------------------------- Happy So I'm really wondering if I'm missing something here that'll help me to determine why Varnish thinks this host is sick! Also I have no problem browsing the custom URLs that I setup on each host to indicate which host apache is running on. Thanks Tim On Sat, May 10, 2014 at 12:58 AM, Tim Dunphy wrote: > Hey all, > > I have two web backends in my varnish config. And one node is reporting > healthy and the other is being reported as 'sick'. > > 10 Backend c 11 www web1 > 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001130 0.001067 > HTTP/1.1 200 OK > 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001231 0.001108 > HTTP/1.1 200 OK > 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001250 0.001143 > HTTP/1.1 200 OK > 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001127 0.001139 > HTTP/1.1 200 OK > 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001208 0.001157 > HTTP/1.1 200 OK > 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001562 0.001258 > HTTP/1.1 200 OK > 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001545 0.001330 > HTTP/1.1 200 OK > 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001363 0.001338 > HTTP/1.1 200 OK > 11 BackendClose b web1 > > [root at varnish1:/etc/varnish] #varnishlog | grep web2 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > > And I'm really at a loss to understand why. Both nodes should be > completely identical. And the web roots on both are basically svn repos > that are in sync. > > From web1 : > > [root at beta:/var/www/jf-current] #svn info | grep -i revision > Revision: 17 > > To web2: > > [root at beta-new:/var/www/jf-current] #svn info | grep -i revision > Revision: 17 > > This is the part of my vcl file where I define the web back ends: > > probe favicon { > .url = "/favicon.ico"; > .timeout = 60ms; > .interval = 2s; > .window = 5; > .threshold = 3; > } > > backend web1 { > .host = "xx.xx.xx.xx"; > .port = "80"; > .probe = favicon; > } > > backend web2 { > > .host = "xx.xx.xx.xx"; > .port = "80"; > .probe = favicon; > } > > And the file that varnish is probing for is present on both: > > [root at beta:/var/www/jf-current] #ls -l /var/www/jf-current/favicon.ico > -rwxrwxr-x 1 apache ftp 1150 Dec 22 00:53 /var/www/jf-current/favicon.ico > > I've also setup individual web URLs for each host that isn't cached in > varnish so I can hit each one. And each site comes up ok. So I'm a little > puzzled as to why the second web host is reporting 'sick' and what I can do > to get it back into load balancing. > > Thanks for any help you can provide! > > Tim > > > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.prats at gmail.com Mon May 12 12:20:26 2014 From: jordi.prats at gmail.com (Jordi Prats) Date: Mon, 12 May 2014 14:20:26 +0200 Subject: varnishsizes fails to display big files Message-ID: Hi, varnishsizes seems to fail to represent big files. I created a several test files to verify it: -rw-r--r-- 1 root root 100M May 12 13:53 100m -rw-r--r-- 1 root root 10M May 12 13:43 10m -rw-r--r-- 1 root root 1000M May 12 13:55 1g -rw-r--r-- 1 root root 1.0M May 12 13:42 1m The 1M file appears at 1e6 in the horitzontal axis, the 10M file at 1e7 and the 100M at 1e8, but the 1G file does not modify the scale (1:1), getting this hit between 1e2 and 1e3 This seems to be a bug, anyone with the same problem? It's a varnish 3 installation in a ubuntu server: [jprats at croscat ~]$ varnishsizes -V varnishsizes (varnish-3.0.5 revision 1a89b1f) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS [jprats at croscat ~]$ 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 +++-===============================-===============================-============================================================================== ii varnish 3.0.5-1~precise state of the art, high-performance web accelerator best regards, -- Jordi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.prats at gmail.com Mon May 12 12:26:06 2014 From: jordi.prats at gmail.com (Jordi Prats) Date: Mon, 12 May 2014 14:26:06 +0200 Subject: varnishsizes fails to display big files In-Reply-To: References: Message-ID: Sorry, I was getting an error I didn't realized... never mind On Mon, May 12, 2014 at 2:20 PM, Jordi Prats wrote: > Hi, > varnishsizes seems to fail to represent big files. > > I created a several test files to verify it: > > -rw-r--r-- 1 root root 100M May 12 13:53 100m > -rw-r--r-- 1 root root 10M May 12 13:43 10m > -rw-r--r-- 1 root root 1000M May 12 13:55 1g > -rw-r--r-- 1 root root 1.0M May 12 13:42 1m > > The 1M file appears at 1e6 in the horitzontal axis, the 10M file at 1e7 > and the 100M at 1e8, but the 1G file does not modify the scale (1:1), > getting this hit between 1e2 and 1e3 > > This seems to be a bug, anyone with the same problem? > > It's a varnish 3 installation in a ubuntu server: > > [jprats at croscat ~]$ varnishsizes -V > varnishsizes (varnish-3.0.5 revision 1a89b1f) > Copyright (c) 2006 Verdens Gang AS > Copyright (c) 2006-2011 Varnish Software AS > > [jprats at croscat ~]$ 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 > > +++-===============================-===============================-============================================================================== > ii varnish 3.0.5-1~precise state > of the art, high-performance web accelerator > > best regards, > -- > Jordi > -- Jordi -------------- next part -------------- An HTML attachment was scrubbed... URL: From japrice at gmail.com Mon May 12 21:33:19 2014 From: japrice at gmail.com (Jason Price) Date: Mon, 12 May 2014 17:33:19 -0400 Subject: System can't take more than 5k req /sec In-Reply-To: References: <535ebc159bd10_5163583282c5656c@a4-wakko5.mail> Message-ID: So, through some TCP tuning we've been able to get to 20k/s. Though I needed to get up to 8k threads per pool. Many docs say 'Don't go more than 4k threads'. Can someone explain that? Anyone have experience with 8-10k threads? --Jason On Tue, Apr 29, 2014 at 10:41 PM, Jason Price wrote: > On Tuesday, April 29, 2014, Norberto Meijome wrote: >> >> Have you ruled out AWS limits? Putting varnish aside for a minute, can you >> handle 5k/sec TCP conns with something like nginx +static files.? > > This is an excellent question. I'll see what kind of answer I'll get to it. > > -Jason From bluethundr at gmail.com Tue May 13 01:56:18 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Mon, 12 May 2014 21:56:18 -0400 Subject: web backend is sick In-Reply-To: References: Message-ID: Hey Jason, Really sorry I have no idea how this happened. But it must have been some very strange copy-paste error that caused what you saw before. In reality I did a wget to web2 and got a response from web2. I grabbed the source text that I created before and checked it for inconstancies and this is what that post should have looked like. Would you or someone on the list care to read over it and try to offer a solution? I must admit I'm tapped for ideas here. But before we retread the following (corrected) info, I've provided a wget to web1 (the good back end) and web2 (the bad back end) by IP: Starting with the bad (sick) back end which is web2 by IP: [root at varnish1:~] #wget -O /dev/null -S http://10.10.1.98/favicon.ico --2014-05-12 21:50:55-- http://166.78.8.98/favicon.ico Connecting to 166.78.8.98:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Tue, 13 May 2014 01:50:56 GMT Server: Apache/2.2.23 (CentOS) Last-Modified: Sat, 10 May 2014 05:06:09 GMT ETag: "1c5461-47e-4f904ac13b240" Accept-Ranges: bytes Content-Length: 1150 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/plain; charset=UTF-8 Length: 1150 (1.1K) [text/plain] Saving to: ?/dev/null? 100%[=========================================================================================>] 1,150 --.-K/s in 0s 2014-05-12 21:50:55 (79.8 MB/s) - ?/dev/null? saved [1150/1150] And now the same thing to the 'healthy' web node (web1) by IP: [root at varnish1:~] #wget -O /dev/null -S http://162.243.109.94/favicon.ico --2014-05-12 21:54:06-- http://162.243.109.94/favicon.ico Connecting to 162.243.109.94:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Tue, 13 May 2014 01:54:05 GMT Server: Apache/2.2.15 (CentOS) Last-Modified: Wed, 05 Mar 2014 19:27:01 GMT ETag: "e123b-47e-4f3e1013feb40" Accept-Ranges: bytes Content-Length: 1150 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: image/vnd.microsoft.icon Length: 1150 (1.1K) [image/vnd.microsoft.icon] Saving to: ?/dev/null? 100%[=========================================================================================>] 1,150 --.-K/s in 0s 2014-05-12 21:54:06 (149 MB/s) - ?/dev/null? saved [1150/1150] And now here is the original (but corrected) version of my previous post! :) Back End node is Sick I am using Varnish to load balance a couple of web nodes using the random load balancing scheme. I took a look at apache on the host that Varnish reports as sick: And apache seems to be running fine on the 'sick' host: [root at beta:/var/www/jf-current] #apachectl -S VirtualHost configuration: wildcard NameVirtualHosts and _default_ servers: *:443 is a NameVirtualHost default server beta.mywebsite.com (/etc/httpd/conf.d/002_jf_beta_ssl.conf:78) port 443 namevhost beta.mywebsite.com (/etc/httpd/conf.d/002_jf_beta_ssl.conf:78) *:80 is a NameVirtualHost default server ref.mywebsite.com (/etc/httpd/conf.d/001_ref.mywebsite.com.conf:1) port 80 namevhost ref.mywebsite.com (/etc/httpd/conf.d/001_ref.mywebsite.com.conf:1) port 80 namevhost qa.mywebsite.com (/etc/httpd/conf.d/002_qa.mywebsite.com.conf:1) port 80 namevhost beta.mywebsite.com (/etc/httpd/conf.d/003_beta.mywebsite.com.conf:1) port 80 namevhost beta-test.mywebsite.com (/etc/httpd/conf.d/004_beta-test.mywebsite.com.conf:1) port 80 namevhost admin.mywebsite.com (/etc/httpd/conf.d/005_admin.mywebsite.com.conf:1) port 80 namevhost admin.mywebsite.com (/etc/httpd/conf.d/10_admin.mywebsite.com.conf:1) port 80 namevhost beta-test.mywebsite.com (/etc/httpd/conf.d/10_beta-test.mywebsite.com.conf:1) port 80 namevhost beta.mywebsite.com (/etc/httpd/conf.d/10_beta.mywebsite.com.conf:1) port 80 namevhost qa.mywebsite.com (/etc/httpd/conf.d/10_qa.mywebsite.com.conf:1) port 80 namevhost ref.mywebsite.com (/etc/httpd/conf.d/10_ref.mywebsite.com.conf:1) Syntax OK My probe and host definitions in the varnish default.vcl looks like this: probe favicon { .url = "/favicon.ico"; .timeout = 34ms; .interval = 1s; .window = 10; .threshold = 8; } backend web1 { .host = "10.10.1.94"; .port = "80"; .probe = favicon; } backend web2 { .host = "10.10.1.98"; .port = "80"; .probe = favicon; } director www random { { .backend = web1 ; .weight = 2; } { .backend = web2 ; .weight = 2; } >From the varnish host I can do a wget for the probe file from the host that varnish is marking as 'sick' [root at varnish1:/etc/varnish] #wget -O /dev/null -S http://web2.mywebsite.com/favicon.ico --2014-05-11 20:48:23-- http://web2.mywebsite.com/favicon.ico Resolving web2.mywebsite.com... 10.10.1.98 Connecting to web2.mywebsite.com |10.10.1.98|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Mon, 12 May 2014 00:48:25 GMT Server: Apache/2.2.23 (CentOS) Last-Modified: Sun, 22 Dec 2013 00:53:19 GMT ETag: "2a8003-47e-4ee14efeebdc0" Accept-Ranges: bytes Content-Length: 1150 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/plain; charset=UTF-8 Length: 1150 (1.1K) [text/plain] Saving to: ?/dev/null? 100%[================================================================>] 1,150 --.-K/s in 0s 2014-05-11 20:48:24 (144 MB/s) - ?/dev/null? saved [1150/1150] I'm attempting here to approximate the calls that varnish is making to determine if a host is healthy. And yet when I try having a look at debug.health from the command line Vaarnish is still labeling it as 'sick' [root at varnish1:~] #varnishadm -T 127.0.0.1:6082 debug.health -S /etc/varnish/secret *Backend web1 is Healthy* Current states good: 10 threshold: 8 window: 10 Average responsetime of good probes: 0.001247 Oldest Newest ================================================================ 4444444444444444444444444444444444444444444444444444444444444444 Good IPv4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy *Backend web2 is Sick* Current states good: 0 threshold: 8 window: 10 Average responsetime of good probes: 0.000000 Oldest Newest ================================================================ ---------------------------------------------------------------- Happy So I'm really wondering if I'm missing something here that'll help me to determine why Varnish thinks this host is sick! Also I have no problem browsing the custom URLs that I setup on each host to indicate which host apache is running on. I would definitely appreciate any clues on how I could handle this. Thanks Tim On Mon, May 12, 2014 at 1:37 AM, Jason Woods wrote: > Hi > > On 12 May 2014, at 01:57, Tim Dunphy wrote: > > I took a look at apache on the host that Varnish reports as sick: > > And apache seems to be running fine on the 'sick' host: > > [root at beta:/var/www/jf-current] #apachectl -S > > VirtualHost configuration: > > wildcard NameVirtualHosts and _default_ servers: > > *:443 is a NameVirtualHost > > default server beta.mywebsite.com(/etc/httpd/conf.d/002_jf_beta_ssl.conf:78) > > port 443 namevhost beta.mywebsite.com(/etc/httpd/conf.d/002_jf_beta_ssl.conf:78) > > *:80 is a NameVirtualHost > > default server ref.mywebsite.com(/etc/httpd/conf.d/001_ref.mywebsite.com.conf:1) > > port 80 namevhost ref.mywebsite.com(/etc/httpd/conf.d/001_ref.mywebsite.com.conf:1) > > port 80 namevhost qa.mywebsite.com(/etc/httpd/conf.d/002_qa.mywebsite.com.conf:1) > > port 80 namevhost beta.mywebsite.com(/etc/httpd/conf.d/003_beta.mywebsite.com.conf:1) > > port 80 namevhost beta-test.mywebsite.com(/etc/httpd/conf.d/004_beta-test.mywebsite.com.conf:1) > > port 80 namevhost admin.mywebsite.com(/etc/httpd/conf.d/005_admin.mywebsite.com.conf:1) > > port 80 namevhost admin.mywebsite.com(/etc/httpd/conf.d/10_admin.mywebsite.com.conf:1) > > port 80 namevhost beta-test.mywebsite.com(/etc/httpd/conf.d/10_beta-test.mywebsite.com.conf:1) > > port 80 namevhost beta.mywebsite.com(/etc/httpd/conf.d/10_beta.mywebsite.com.conf:1) > > port 80 namevhost qa.mywebsite.com(/etc/httpd/conf.d/10_qa.mywebsite.com.conf:1) > > port 80 namevhost ref.mywebsite.com(/etc/httpd/conf.d/10_ref.mywebsite.com.conf:1) > > Syntax OK > > > My probe and host definitions in the varnish default.vcl looks like this: > > > probe favicon { > > .url = "/favicon.ico"; > > .timeout = 34ms; > > .interval = 1s; > > .window = 10; > > .threshold = 8; > > } > > > backend web1 { > > .host = "10.10.1.94"; > > .port = "80"; > > .probe = favicon; > > } > > > backend web2 { > > > .host = "10.10.1.98"; > > .port = "80"; > > .probe = favicon; > > } > > director www random { > > { .backend = web1 ; .weight = 2; } > > { .backend = web2 ; .weight = 2; } > > } > I was just experimenting the load balancing algorithms, but that probably > doesn't have much bearing on this problem. > > From the varnish host I can do a wget for the probe file from the host > that varnish is marking as 'sick' > > > [root at varnish1:/etc/varnish] #wget -O /dev/null -S > http://web2.mywebsite.com/favicon.ico > > --2014-05-11 20:48:23-- http://web1.mywebsite.com/favicon.ico > > > You request web2 but it resolved web1? This may be related to the cause. > > Can you wget both web1 and web2? Using IP too? (If I'm honest I'm not sure > what Host header Varnish will request with.) > > Jason > > Resolving web1.mywebsite.com... 10.10.1.98 > > Connecting to web1.mywebsite.com|10.10.1.98|:80... connected. > > HTTP request sent, awaiting response... > > HTTP/1.1 200 OK > > Date: Mon, 12 May 2014 00:48:25 GMT > > Server: Apache/2.2.23 (CentOS) > > Last-Modified: Sun, 22 Dec 2013 00:53:19 GMT > > ETag: "2a8003-47e-4ee14efeebdc0" > > Accept-Ranges: bytes > > Content-Length: 1150 > > Keep-Alive: timeout=5, max=100 > > Connection: Keep-Alive > > Content-Type: text/plain; charset=UTF-8 > > Length: 1150 (1.1K) [text/plain] > > Saving to: ?/dev/null? > > 100%[================================================================>] > 1,150 --.-K/s in 0s > > 2014-05-11 20:48:24 (144 MB/s) - ?/dev/null? saved [1150/1150] > > > I'm attempting here to approximate the calls that varnish is making to > determine if a host is healthy. > > And yet when I try having a look at debug.health from the command line > Vaarnish is still labeling it as 'sick' > > [root at varnish1:~] #varnishadm -T 127.0.0.1:6082 debug.health -S > /etc/varnish/secret > > *Backend web1 is Healthy* > > Current states good: 10 threshold: 8 window: 10 > > Average responsetime of good probes: 0.001247 > > Oldest Newest > > ================================================================ > > 4444444444444444444444444444444444444444444444444444444444444444 Good IPv4 > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit > > RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv > > HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy > > *Backend web2 is Sick* > > Current states good: 0 threshold: 8 window: 10 > > Average responsetime of good probes: 0.000000 > > Oldest Newest > > ================================================================ > > ---------------------------------------------------------------- Happy > > So I'm really wondering if I'm missing something here that'll help me to > determine why Varnish thinks this host is sick! Also I have no problem > browsing the custom URLs that I setup on each host to indicate which host > apache is running on. > > > Thanks > > Tim > > > > On Sat, May 10, 2014 at 12:58 AM, Tim Dunphy wrote: > >> Hey all, >> >> I have two web backends in my varnish config. And one node is reporting >> healthy and the other is being reported as 'sick'. >> >> 10 Backend c 11 www web1 >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001130 0.001067 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001231 0.001108 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001250 0.001143 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001127 0.001139 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001208 0.001157 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001562 0.001258 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001545 0.001330 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001363 0.001338 >> HTTP/1.1 200 OK >> 11 BackendClose b web1 >> >> [root at varnish1:/etc/varnish] #varnishlog | grep web2 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> >> And I'm really at a loss to understand why. Both nodes should be >> completely identical. And the web roots on both are basically svn repos >> that are in sync. >> >> From web1 : >> >> [root at beta:/var/www/jf-current] #svn info | grep -i revision >> Revision: 17 >> >> To web2: >> >> [root at beta-new:/var/www/jf-current] #svn info | grep -i revision >> Revision: 17 >> >> This is the part of my vcl file where I define the web back ends: >> >> probe favicon { >> .url = "/favicon.ico"; >> .timeout = 60ms; >> .interval = 2s; >> .window = 5; >> .threshold = 3; >> } >> >> backend web1 { >> .host = "xx.xx.xx.xx"; >> .port = "80"; >> .probe = favicon; >> } >> >> backend web2 { >> >> .host = "xx.xx.xx.xx"; >> .port = "80"; >> .probe = favicon; >> } >> >> And the file that varnish is probing for is present on both: >> >> [root at beta:/var/www/jf-current] #ls -l /var/www/jf-current/favicon.ico >> -rwxrwxr-x 1 apache ftp 1150 Dec 22 00:53 /var/www/jf-current/favicon.ico >> >> I've also setup individual web URLs for each host that isn't cached in >> varnish so I can hit each one. And each site comes up ok. So I'm a little >> puzzled as to why the second web host is reporting 'sick' and what I can do >> to get it back into load balancing. >> >> Thanks for any help you can provide! >> >> Tim >> >> >> >> >> >> -- >> GPG me!! >> >> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B >> >> > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluethundr at gmail.com Tue May 13 03:03:14 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Mon, 12 May 2014 23:03:14 -0400 Subject: web backend is sick In-Reply-To: References: Message-ID: Hi Nick, Thanks for your reply! I tried a different probe. No luck so far: backend web1 { .host = "10.10.1.94"; .port = "80"; .probe = { .url = "/healthcheck.html"; .timeout = 34 ms; .interval = 1s; .window = 10; .threshold = 8; } } backend web2 { .host = "10.10.1.98"; .port = "80"; .probe = { .url = "/healthcheck.html"; .timeout = 34 ms; .interval = 1s; .window = 10; .threshold = 8; } } director www client { { .backend = web1 ; .weight = 2; } { .backend = web2 ; .weight = 2; } } This is all the healthcheck file does: [root at beta:/var/www/jf-ref] #cat healthcheck.html good Drum roll please!! AAAAnnnnnd: [root at varnish1:/etc/varnish] #varnishlog | grep web2 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 Bummer. :( No joy at all. Thanks for playing! Tim On Mon, May 12, 2014 at 10:03 PM, nick tailor wrote: > Try using a custom health check probe > On May 9, 2014 10:00 PM, "Tim Dunphy" wrote: > >> Hey all, >> >> I have two web backends in my varnish config. And one node is reporting >> healthy and the other is being reported as 'sick'. >> >> 10 Backend c 11 www web1 >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001130 0.001067 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001231 0.001108 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001250 0.001143 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001127 0.001139 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001208 0.001157 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001562 0.001258 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001545 0.001330 >> HTTP/1.1 200 OK >> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001363 0.001338 >> HTTP/1.1 200 OK >> 11 BackendClose b web1 >> >> [root at varnish1:/etc/varnish] #varnishlog | grep web2 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >> >> And I'm really at a loss to understand why. Both nodes should be >> completely identical. And the web roots on both are basically svn repos >> that are in sync. >> >> From web1 : >> >> [root at beta:/var/www/jf-current] #svn info | grep -i revision >> Revision: 17 >> >> To web2: >> >> [root at beta-new:/var/www/jf-current] #svn info | grep -i revision >> Revision: 17 >> >> This is the part of my vcl file where I define the web back ends: >> >> probe favicon { >> .url = "/favicon.ico"; >> .timeout = 60ms; >> .interval = 2s; >> .window = 5; >> .threshold = 3; >> } >> >> backend web1 { >> .host = "xx.xx.xx.xx"; >> .port = "80"; >> .probe = favicon; >> } >> >> backend web2 { >> >> .host = "xx.xx.xx.xx"; >> .port = "80"; >> .probe = favicon; >> } >> >> And the file that varnish is probing for is present on both: >> >> [root at beta:/var/www/jf-current] #ls -l /var/www/jf-current/favicon.ico >> -rwxrwxr-x 1 apache ftp 1150 Dec 22 00:53 /var/www/jf-current/favicon.ico >> >> I've also setup individual web URLs for each host that isn't cached in >> varnish so I can hit each one. And each site comes up ok. So I'm a little >> puzzled as to why the second web host is reporting 'sick' and what I can do >> to get it back into load balancing. >> >> Thanks for any help you can provide! >> >> Tim >> >> >> >> >> >> -- >> GPG me!! >> >> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B >> >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From stef at scaleengine.com Tue May 13 03:13:16 2014 From: stef at scaleengine.com (Stefan Caunter) Date: Mon, 12 May 2014 23:13:16 -0400 Subject: web backend is sick In-Reply-To: References: Message-ID: 34 milliseconds? You are asking for your backend to get marked sick all the time with this value on an apache server. You just want to know if it has totally gone away. Set the timeout to 5 seconds. You can do some beautiful tuning if you really understand your web app and want to move varnish away from sick backends, but for now, you just need to use both your backends, and let varnish protect them. ---- Stefan Caunter ScaleEngine Inc. E: stefan.caunter at scaleengine.com Toronto Canada On Mon, May 12, 2014 at 11:03 PM, Tim Dunphy wrote: > Hi Nick, > > Thanks for your reply! I tried a different probe. No luck so far: > > backend web1 { > .host = "10.10.1.94"; > .port = "80"; > .probe = { > .url = "/healthcheck.html"; > .timeout = 34 ms; > .interval = 1s; > .window = 10; > .threshold = 8; > } > } > > backend web2 { > > .host = "10.10.1.98"; > .port = "80"; > .probe = { > .url = "/healthcheck.html"; > .timeout = 34 ms; > .interval = 1s; > .window = 10; > .threshold = 8; > } > } > > director www client { > { .backend = web1 ; .weight = 2; } > { .backend = web2 ; .weight = 2; } > } > > > This is all the healthcheck file does: > > [root at beta:/var/www/jf-ref] #cat healthcheck.html > good > > Drum roll please!! AAAAnnnnnd: > > [root at varnish1:/etc/varnish] #varnishlog | grep web2 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > Bummer. :( > > No joy at all. > > Thanks for playing! > Tim > > > On Mon, May 12, 2014 at 10:03 PM, nick tailor wrote: >> >> Try using a custom health check probe >> >> On May 9, 2014 10:00 PM, "Tim Dunphy" wrote: >>> >>> Hey all, >>> >>> I have two web backends in my varnish config. And one node is reporting >>> healthy and the other is being reported as 'sick'. >>> >>> 10 Backend c 11 www web1 >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001130 0.001067 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001231 0.001108 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001250 0.001143 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001127 0.001139 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001208 0.001157 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001562 0.001258 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001545 0.001330 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001363 0.001338 >>> HTTP/1.1 200 OK >>> 11 BackendClose b web1 >>> >>> [root at varnish1:/etc/varnish] #varnishlog | grep web2 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> >>> And I'm really at a loss to understand why. Both nodes should be >>> completely identical. And the web roots on both are basically svn repos that >>> are in sync. >>> >>> From web1 : >>> >>> [root at beta:/var/www/jf-current] #svn info | grep -i revision >>> Revision: 17 >>> >>> To web2: >>> >>> [root at beta-new:/var/www/jf-current] #svn info | grep -i revision >>> Revision: 17 >>> >>> This is the part of my vcl file where I define the web back ends: >>> >>> probe favicon { >>> .url = "/favicon.ico"; >>> .timeout = 60ms; >>> .interval = 2s; >>> .window = 5; >>> .threshold = 3; >>> } >>> >>> backend web1 { >>> .host = "xx.xx.xx.xx"; >>> .port = "80"; >>> .probe = favicon; >>> } >>> >>> backend web2 { >>> >>> .host = "xx.xx.xx.xx"; >>> .port = "80"; >>> .probe = favicon; >>> } >>> >>> And the file that varnish is probing for is present on both: >>> >>> [root at beta:/var/www/jf-current] #ls -l /var/www/jf-current/favicon.ico >>> -rwxrwxr-x 1 apache ftp 1150 Dec 22 00:53 /var/www/jf-current/favicon.ico >>> >>> I've also setup individual web URLs for each host that isn't cached in >>> varnish so I can hit each one. And each site comes up ok. So I'm a little >>> puzzled as to why the second web host is reporting 'sick' and what I can do >>> to get it back into load balancing. >>> >>> Thanks for any help you can provide! >>> >>> Tim >>> >>> >>> >>> >>> >>> -- >>> GPG me!! >>> >>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B >>> >>> >>> _______________________________________________ >>> varnish-misc mailing list >>> varnish-misc at varnish-cache.org >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From bluethundr at gmail.com Tue May 13 03:43:23 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Mon, 12 May 2014 23:43:23 -0400 Subject: web backend is sick In-Reply-To: References: Message-ID: Hey, Ok so I took your advice and changed the value to 5 ms. And yeah, honestly I kind of just mindlessly pasted an example I found on the web into my VCL. It's late here and I want to go to bed. But the curiosity I have on how to solve this is killing me! ;) And I would think that giving the servers longer to time out would actually help varnish realize the server is ok. Which in fact it appears to be. But for the sake of argument I tried changing the values to what you suggest and bounced varnish. No change yet. backend web1 { .host = "10.10.1.94"; .port = "80"; .probe = { .url = "/healthcheck.html"; .timeout = 5 ms; .interval = 1s; .window = 10; .threshold = 8; } } backend web2 { .host = "10.10.1.98"; .port = "80"; .probe = { .url = "/healthcheck.html"; .timeout = 5 ms; .interval = 1s; .window = 10; .threshold = 8; } } director www client { { .backend = web1 ; .weight = 2; } { .backend = web2 ; .weight = 2; } } So like I said no expected change and none produced. [root at varnish1:/etc/varnish] #varnishlog | grep web2 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 Thanks Tim On Mon, May 12, 2014 at 11:13 PM, Stefan Caunter wrote: > 34 milliseconds? You are asking for your backend to get marked sick > all the time with this value on an apache server. You just want to > know if it has totally gone away. Set the timeout to 5 seconds. You > can do some beautiful tuning if you really understand your web app and > want to move varnish away from sick backends, but for now, you just > need to use both your backends, and let varnish protect them. > > > ---- > > Stefan Caunter > ScaleEngine Inc. > E: stefan.caunter at scaleengine.com > Toronto Canada > > > On Mon, May 12, 2014 at 11:03 PM, Tim Dunphy wrote: > > Hi Nick, > > > > Thanks for your reply! I tried a different probe. No luck so far: > > > > backend web1 { > > .host = "10.10.1.94"; > > .port = "80"; > > .probe = { > > .url = "/healthcheck.html"; > > .timeout = 34 ms; > > .interval = 1s; > > .window = 10; > > .threshold = 8; > > } > > } > > > > backend web2 { > > > > .host = "10.10.1.98"; > > .port = "80"; > > .probe = { > > .url = "/healthcheck.html"; > > .timeout = 34 ms; > > .interval = 1s; > > .window = 10; > > .threshold = 8; > > } > > } > > > > director www client { > > { .backend = web1 ; .weight = 2; } > > { .backend = web2 ; .weight = 2; } > > } > > > > > > This is all the healthcheck file does: > > > > [root at beta:/var/www/jf-ref] #cat healthcheck.html > > good > > > > Drum roll please!! AAAAnnnnnd: > > > > [root at varnish1:/etc/varnish] #varnishlog | grep web2 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > > > Bummer. :( > > > > No joy at all. > > > > Thanks for playing! > > Tim > > > > > > On Mon, May 12, 2014 at 10:03 PM, nick tailor > wrote: > >> > >> Try using a custom health check probe > >> > >> On May 9, 2014 10:00 PM, "Tim Dunphy" wrote: > >>> > >>> Hey all, > >>> > >>> I have two web backends in my varnish config. And one node is > reporting > >>> healthy and the other is being reported as 'sick'. > >>> > >>> 10 Backend c 11 www web1 > >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001130 > 0.001067 > >>> HTTP/1.1 200 OK > >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001231 > 0.001108 > >>> HTTP/1.1 200 OK > >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001250 > 0.001143 > >>> HTTP/1.1 200 OK > >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001127 > 0.001139 > >>> HTTP/1.1 200 OK > >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001208 > 0.001157 > >>> HTTP/1.1 200 OK > >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001562 > 0.001258 > >>> HTTP/1.1 200 OK > >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001545 > 0.001330 > >>> HTTP/1.1 200 OK > >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001363 > 0.001338 > >>> HTTP/1.1 200 OK > >>> 11 BackendClose b web1 > >>> > >>> [root at varnish1:/etc/varnish] #varnishlog | grep web2 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 > >>> > >>> And I'm really at a loss to understand why. Both nodes should be > >>> completely identical. And the web roots on both are basically svn > repos that > >>> are in sync. > >>> > >>> From web1 : > >>> > >>> [root at beta:/var/www/jf-current] #svn info | grep -i revision > >>> Revision: 17 > >>> > >>> To web2: > >>> > >>> [root at beta-new:/var/www/jf-current] #svn info | grep -i revision > >>> Revision: 17 > >>> > >>> This is the part of my vcl file where I define the web back ends: > >>> > >>> probe favicon { > >>> .url = "/favicon.ico"; > >>> .timeout = 60ms; > >>> .interval = 2s; > >>> .window = 5; > >>> .threshold = 3; > >>> } > >>> > >>> backend web1 { > >>> .host = "xx.xx.xx.xx"; > >>> .port = "80"; > >>> .probe = favicon; > >>> } > >>> > >>> backend web2 { > >>> > >>> .host = "xx.xx.xx.xx"; > >>> .port = "80"; > >>> .probe = favicon; > >>> } > >>> > >>> And the file that varnish is probing for is present on both: > >>> > >>> [root at beta:/var/www/jf-current] #ls -l /var/www/jf-current/favicon.ico > >>> -rwxrwxr-x 1 apache ftp 1150 Dec 22 00:53 > /var/www/jf-current/favicon.ico > >>> > >>> I've also setup individual web URLs for each host that isn't cached in > >>> varnish so I can hit each one. And each site comes up ok. So I'm a > little > >>> puzzled as to why the second web host is reporting 'sick' and what I > can do > >>> to get it back into load balancing. > >>> > >>> Thanks for any help you can provide! > >>> > >>> Tim > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> GPG me!! > >>> > >>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > >>> > >>> > >>> _______________________________________________ > >>> varnish-misc mailing list > >>> varnish-misc at varnish-cache.org > >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > > > > > > > > > -- > > GPG me!! > > > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > > > > _______________________________________________ > > varnish-misc mailing list > > varnish-misc at varnish-cache.org > > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From Travis.Crowder at penton.com Tue May 13 04:22:42 2014 From: Travis.Crowder at penton.com (Crowder, Travis) Date: Tue, 13 May 2014 04:22:42 +0000 Subject: web backend is sick In-Reply-To: References: , Message-ID: <773091B1-3631-46AB-9B17-BE4A3B0977E7@penton.com> 5 seconds, not milliseconds. Sent from my iPhone On May 12, 2014, at 10:49 PM, "Tim Dunphy" > wrote: Hey, Ok so I took your advice and changed the value to 5 ms. And yeah, honestly I kind of just mindlessly pasted an example I found on the web into my VCL. It's late here and I want to go to bed. But the curiosity I have on how to solve this is killing me! ;) And I would think that giving the servers longer to time out would actually help varnish realize the server is ok. Which in fact it appears to be. But for the sake of argument I tried changing the values to what you suggest and bounced varnish. No change yet. backend web1 { .host = "10.10.1.94"; .port = "80"; .probe = { .url = "/healthcheck.html"; .timeout = 5 ms; .interval = 1s; .window = 10; .threshold = 8; } } backend web2 { .host = "10.10.1.98"; .port = "80"; .probe = { .url = "/healthcheck.html"; .timeout = 5 ms; .interval = 1s; .window = 10; .threshold = 8; } } director www client { { .backend = web1 ; .weight = 2; } { .backend = web2 ; .weight = 2; } } So like I said no expected change and none produced. [root at varnish1:/etc/varnish] #varnishlog | grep web2 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 Thanks Tim On Mon, May 12, 2014 at 11:13 PM, Stefan Caunter > wrote: 34 milliseconds? You are asking for your backend to get marked sick all the time with this value on an apache server. You just want to know if it has totally gone away. Set the timeout to 5 seconds. You can do some beautiful tuning if you really understand your web app and want to move varnish away from sick backends, but for now, you just need to use both your backends, and let varnish protect them. ---- Stefan Caunter ScaleEngine Inc. E: stefan.caunter at scaleengine.com Toronto Canada On Mon, May 12, 2014 at 11:03 PM, Tim Dunphy > wrote: > Hi Nick, > > Thanks for your reply! I tried a different probe. No luck so far: > > backend web1 { > .host = "10.10.1.94"; > .port = "80"; > .probe = { > .url = "/healthcheck.html"; > .timeout = 34 ms; > .interval = 1s; > .window = 10; > .threshold = 8; > } > } > > backend web2 { > > .host = "10.10.1.98"; > .port = "80"; > .probe = { > .url = "/healthcheck.html"; > .timeout = 34 ms; > .interval = 1s; > .window = 10; > .threshold = 8; > } > } > > director www client { > { .backend = web1 ; .weight = 2; } > { .backend = web2 ; .weight = 2; } > } > > > This is all the healthcheck file does: > > [root at beta:/var/www/jf-ref] #cat healthcheck.html > good > > Drum roll please!! AAAAnnnnnd: > > [root at varnish1:/etc/varnish] #varnishlog | grep web2 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > 0 Backend_health - web2 Still sick ------- 0 8 10 0.000000 0.000000 > > Bummer. :( > > No joy at all. > > Thanks for playing! > Tim > > > On Mon, May 12, 2014 at 10:03 PM, nick tailor > wrote: >> >> Try using a custom health check probe >> >> On May 9, 2014 10:00 PM, "Tim Dunphy" > wrote: >>> >>> Hey all, >>> >>> I have two web backends in my varnish config. And one node is reporting >>> healthy and the other is being reported as 'sick'. >>> >>> 10 Backend c 11 www web1 >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001130 0.001067 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001231 0.001108 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001250 0.001143 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001127 0.001139 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001208 0.001157 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001562 0.001258 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001545 0.001330 >>> HTTP/1.1 200 OK >>> 0 Backend_health - web1 Still healthy 4--X-RH 5 3 5 0.001363 0.001338 >>> HTTP/1.1 200 OK >>> 11 BackendClose b web1 >>> >>> [root at varnish1:/etc/varnish] #varnishlog | grep web2 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> 0 Backend_health - web2 Still sick 4--X--- 0 3 5 0.000000 0.000000 >>> >>> And I'm really at a loss to understand why. Both nodes should be >>> completely identical. And the web roots on both are basically svn repos that >>> are in sync. >>> >>> From web1 : >>> >>> [root at beta:/var/www/jf-current] #svn info | grep -i revision >>> Revision: 17 >>> >>> To web2: >>> >>> [root at beta-new:/var/www/jf-current] #svn info | grep -i revision >>> Revision: 17 >>> >>> This is the part of my vcl file where I define the web back ends: >>> >>> probe favicon { >>> .url = "/favicon.ico"; >>> .timeout = 60ms; >>> .interval = 2s; >>> .window = 5; >>> .threshold = 3; >>> } >>> >>> backend web1 { >>> .host = "xx.xx.xx.xx"; >>> .port = "80"; >>> .probe = favicon; >>> } >>> >>> backend web2 { >>> >>> .host = "xx.xx.xx.xx"; >>> .port = "80"; >>> .probe = favicon; >>> } >>> >>> And the file that varnish is probing for is present on both: >>> >>> [root at beta:/var/www/jf-current] #ls -l /var/www/jf-current/favicon.ico >>> -rwxrwxr-x 1 apache ftp 1150 Dec 22 00:53 /var/www/jf-current/favicon.ico >>> >>> I've also setup individual web URLs for each host that isn't cached in >>> varnish so I can hit each one. And each site comes up ok. So I'm a little >>> puzzled as to why the second web host is reporting 'sick' and what I can do >>> to get it back into load balancing. >>> >>> Thanks for any help you can provide! >>> >>> Tim >>> >>> >>> >>> >>> >>> -- >>> GPG me!! >>> >>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B >>> >>> >>> _______________________________________________ >>> varnish-misc mailing list >>> varnish-misc at varnish-cache.org >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B _______________________________________________ varnish-misc mailing list varnish-misc at varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From girish.marwah at icreon.com Tue May 13 10:55:03 2014 From: girish.marwah at icreon.com (Girish Marwah) Date: Tue, 13 May 2014 16:25:03 +0530 Subject: Varnish on load balancer Message-ID: <006501cf6e99$cd49c810$67dd5830$@icreon.com> Hi, I am configuring varnish with apache on a separate server. Setup is like, we have one load balancer from Amazon and from load balancer load is distributing to two varnish servers. Varnish listening port is 80. And then we have two web servers running apache at port 80 as well. Web servers are acting as backend servers to both varnish machines. Amazon Elastic Load Balancer rule is: 443 (HTTPS, Certificate: xxx) forwarding to 80 (HTTP) on varnish servers. There is no virtual host on web server listen on 443, virtual host is on 80. Please confirm this is the right configuration for the setup. Thanks Girish -------------- next part -------------- An HTML attachment was scrubbed... URL: From japrice at gmail.com Tue May 13 13:31:16 2014 From: japrice at gmail.com (Jason Price) Date: Tue, 13 May 2014 09:31:16 -0400 Subject: System can't take more than 5k req /sec In-Reply-To: <9f0fd75294054cccb1ca9b759443d33a@AM3PR02MB178.eurprd02.prod.outlook.com> References: <535ebc159bd10_5163583282c5656c@a4-wakko5.mail> <9f0fd75294054cccb1ca9b759443d33a@AM3PR02MB178.eurprd02.prod.outlook.com> Message-ID: Private message requesting TCP tuning. For the record, these are draft numbers and very tightly tied to our use case, so they should not be copied blindly. somaxconn is 512 txqueuelen is 5000 netdev_max_backlog is 5000 tcp_max_syn_backlog is 4096 enable tcp_tw_recycle enable tcp_tw_reuse On Tue, May 13, 2014 at 6:45 AM, ??????? ????????????? wrote: > Could you please give us some more information about your > TCP tuning? > Regards > Yiannis > > -----Original Message----- > From: varnish-misc-bounces+gkaragiannidis=dolnet.gr at varnish-cache.org [mailto:varnish-misc-bounces+gkaragiannidis=dolnet.gr at varnish-cache.org] On Behalf Of Jason Price > Sent: Tuesday, May 13, 2014 12:33 AM > To: Norberto Meijome > Cc: varnish-misc at varnish-cache.org > Subject: Re: System can't take more than 5k req /sec > > So, through some TCP tuning we've been able to get to 20k/s. Though I needed to get up to 8k threads per pool. > > Many docs say 'Don't go more than 4k threads'. Can someone explain that? Anyone have experience with 8-10k threads? > > --Jason > > On Tue, Apr 29, 2014 at 10:41 PM, Jason Price wrote: >> On Tuesday, April 29, 2014, Norberto Meijome wrote: >>> >>> Have you ruled out AWS limits? Putting varnish aside for a minute, >>> can you handle 5k/sec TCP conns with something like nginx +static files.? >> >> This is an excellent question. I'll see what kind of answer I'll get to it. >> >> -Jason > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From bluethundr at gmail.com Wed May 14 03:30:14 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Tue, 13 May 2014 23:30:14 -0400 Subject: site goes down if same one of two varnish nodes stopped In-Reply-To: References: <8622E7F3-6DDA-46B1-80FD-4D7A5E1886CC@psu.edu> Message-ID: HI Jason and others, I just wanted to let you know that this pretty much solved my problem. This problem was most definitely relating to the F5 load balancers. Basically the F5 guy I was dealing with had to set an option called "Reconnects' to a value of 3 from a value of 0. Apparently if this option is set to 0, then the F5 cannot load balancer whatever it's trying to. This was a valuable lesson and something to keep in mind for the future. Thanks again! Tim On Sun, May 11, 2014 at 8:33 PM, Tim Dunphy wrote: > It sounds like you are using a tcp monitor on your F5 from reading over at >> first glance. If varnish goes down, but the system stays up, your monitor >> wouldn?t remove the node from the pool and keeps sending connections to >> that node. You want to use a custom monitor like in the attached image in >> combination with this in your vcl. You can test this by stopping one of >> your varnish nodes and seeing if it is marked down in the pool. >> // add ping url to test Varnish status >> if (req.request == "GET" && req.url ~ "/varnish-ping") { >> error 200 "OK"; >> } > > > > Hi Jason, > > Thank you very much for your reply. And yeah, I sort of think this is an > issue with the F5 and not with Varnish. Mainly because both Varnish > instances are identically installed and configured. I don't actually have > direct access to the F5 at work. But one of the F5 guys that I deal with is > very easy going and I'm sure will be ready to help. > > I'll ping him with this scenario tomorrow. Thank you for confirming my > suspicion that this issue is likely on the F5 end and not the Varnish end. > > Thanks > Tim > > > On Sun, May 11, 2014 at 8:08 PM, Jason Heffner wrote: > >> It sounds like you are using a tcp monitor on your F5 from reading over >> at first glance. If varnish goes down, but the system stays up, your >> monitor wouldn?t remove the node from the pool and keeps sending >> connections to that node. You want to use a custom monitor like in the >> attached image in combination with this in your vcl. You can test this by >> stopping one of your varnish nodes and seeing if it is marked down in the >> pool. >> >> // add ping url to test Varnish status >> if (req.request == "GET" && req.url ~ "/varnish-ping") { >> error 200 "OK"; >> } >> >> >> Jason >> >> p: (814) 865-1840, c: (814) 777-7665 >> Systems Administrator >> Teaching and Learning with Technology, Information Technology Services >> The Pennsylvania State University >> >> On May 11, 2014, at 7:15 PM, Tim Dunphy wrote: >> >> Hey guys, >> >> One more interesting thing about my situation. Is that if I do a >> varnishstat command on both node A (which seems to control the site) and >> node B (which does not seem to), I get further evidence that both nodes are >> supporting the site. >> >> >> 0+02:10:12 >> *uszmpwsls014la* >> >> Hitrate ratio: 4 4 4 >> >> Hitrate avg: 0.9977 0.9977 0.9977 >> >> >> 3139 1.00 0.40 Client connections accepted >> >> 3149 1.00 0.40 Client requests received >> >> 3120 1.00 0.40 Cache hits >> >> 29 0.00 0.00 Cache misses >> >> 25 0.00 0.00 Backend conn. success >> >> 4 0.00 0.00 Backend conn. reuses >> >> 20 0.00 0.00 Backend conn. was closed >> >> 26 0.00 0.00 Backend conn. recycles >> >> 29 0.00 0.00 Fetch with Length >> >> 16 . . N struct sess_mem >> >> 26 . . N struct object >> >> 36 . . N struct objectcore >> >> 25 . . N struct objecthead >> >> 2 . . N struct vbe_conn >> >> 500 . . N worker threads >> >> 500 0.00 0.06 N worker threads created >> >> 3 . . N backends >> >> 1563 . . N LRU moved objects >> >> 3128 1.00 0.40 Objects sent with write >> >> 3139 1.00 0.40 Total Sessions >> >> >> 0+03:04:56 >> *uszmpwsls014lb* >> >> Hitrate ratio: 10 21 21 >> >> Hitrate avg: 0.9999 0.9998 0.9998 >> >> >> 4440 2.00 0.40 Client connections accepted >> >> 4440 2.00 0.40 Client requests received >> >> 4421 2.00 0.40 Cache hits >> >> 19 0.00 0.00 Cache misses >> >> 19 0.00 0.00 Backend conn. success >> >> 16 0.00 0.00 Backend conn. was closed >> >> 19 0.00 0.00 Backend conn. recycles >> >> 19 0.00 0.00 Fetch with Length >> >> 10 . . N struct sess_mem >> >> 19 . . N struct object >> >> 29 . . N struct objectcore >> >> 11 . . N struct objecthead >> >> 3 . . N struct vbe_conn >> >> 500 . . N worker threads >> >> 500 0.00 0.05 N worker threads created >> >> 3 . . N backends >> >> 2209 . . N LRU moved objects >> >> 4440 2.00 0.40 Objects sent with write >> >> 4440 2.00 0.40 Total Sessions >> >> 4440 2.00 0.40 Total Requests >> >> So why the entire site goes down when I bring down node A but leave up >> node B I am still a little puzzled by. Unless the explanation may be that >> the F5 is NOT balancing the two varnish nodes in quite the way I appear to >> think. But if that is the case, then why do we see almost identical stats >> coming out of both hosts? >> >> >> Thanks >> >> Tim >> >> >> On Sun, May 11, 2014 at 6:20 PM, Tim Dunphy wrote: >> >>> hey all.. >>> >>> I have two varnish nodes being balanced by an F5 load balancer both were >>> installed in the same exact manner with yum installing local rpms of >>> varnish 2.1.5 (the requested version of the client). >>> >>> Both share the exact same default.vcl file. But if you take node a down >>> with node b running the whole site goes down if you take node b down with >>> node a running the site stays up. I need to determine why node b isn't >>> supporting the site. Each varnish node needs to be balancing 3 web servers >>> and it looks like the a node does. Since the site goes down when you take >>> down node a and leave node b running >>> >>> I had a look at varnishlog for both and both nodes appear to be getting >>> hit. >>> >>> Node A: >>> >>> 3 VCL_return c deliver >>> >>> 3 TxProtocol c HTTP/1.1 >>> >>> 3 TxStatus c 200 >>> >>> 3 TxResponse c OK >>> >>> 3 TxHeader c Server: Apache >>> >>> 3 TxHeader c X-Powered-By: PHP/5.2.8 >>> >>> 3 TxHeader c Content-Type: text/html >>> >>> 3 TxHeader c Cache-Control: max-age = 600 >>> >>> 3 TxHeader c Content-Length: 4 >>> >>> 3 TxHeader c Date: Sun, 11 May 2014 22:11:02 GMT >>> >>> 3 TxHeader c X-Varnish: 1578371599 1578371564 >>> >>> 3 TxHeader c Age: 86 >>> >>> 3 TxHeader c Via: 1.1 varnish >>> >>> 3 TxHeader c Connection: close >>> >>> 3 TxHeader c Varnish-X-Cache: HIT >>> >>> 3 TxHeader c Varnish-X-Cache-Hits: 35 >>> >>> 3 Length c 4 >>> >>> 3 ReqEnd c 1578371599 1399846262.156239033 >>> 1399846262.156332970 0.000054121 0.000056028 0.000037909 >>> >>> >>> Node B: >>> >>> 9 VCL_return c deliver >>> >>> 9 TxProtocol c HTTP/1.1 >>> >>> 9 TxStatus c 200 >>> >>> 9 TxResponse c OK >>> >>> 9 TxHeader c Server: Apache >>> >>> 9 TxHeader c X-Powered-By: PHP/5.2.17 >>> >>> 9 TxHeader c Content-Type: text/html >>> >>> 9 TxHeader c Cache-Control: max-age = 600 >>> >>> 9 TxHeader c Content-Length: 4 >>> >>> 9 TxHeader c Date: Sun, 11 May 2014 22:11:33 GMT >>> >>> 9 TxHeader c X-Varnish: 1525629213 1525629076 >>> >>> 9 TxHeader c Age: 341 >>> >>> 9 TxHeader c Via: 1.1 varnish >>> >>> 9 TxHeader c Connection: close >>> >>> 9 TxHeader c Varnish-X-Cache: HIT >>> >>> 9 TxHeader c Varnish-X-Cache-Hits: 137 >>> >>> 9 Length c 4 >>> >>> 9 ReqEnd c 1525629213 1399846293.098695993 >>> 1399846293.098922968 0.000057936 0.000181913 0.000045061 >>> >>> So I'm not sure why this is the case. >>> >>> Here?s the VCL file that I?m using in case this might shed any clues. I >>> apologize that I?m still to much of a newb to ferret out the most relevant >>> parts. But I hope that the context may yield some clues. >>> >>> backend web1 { >>> >>> .host = "10.10.1.104"; >>> >>> .port = "80"; >>> >>> .connect_timeout = 45s; >>> >>> .first_byte_timeout = 45s; >>> >>> .between_bytes_timeout = 45s; >>> >>> .max_connections = 70; >>> >>> .probe = { >>> >>> .url = "/healthcheck.php"; >>> >>> .timeout = 5s; >>> >>> .interval = 30s; >>> >>> .window = 10; >>> >>> .threshold = 1; >>> >>> } >>> >>> } >>> >>> backend web2 { >>> >>> .host = "10.10.1.105"; >>> >>> .port = "80"; >>> >>> .connect_timeout = 45s; >>> >>> .first_byte_timeout = 45s; >>> >>> .between_bytes_timeout = 45s; >>> >>> .max_connections = 70; >>> >>> .probe = { >>> >>> .url = "/healthcheck.php"; >>> >>> .timeout = 5s; >>> >>> .interval = 30s; >>> >>> .window = 10; >>> >>> .threshold = 1; >>> >>> } >>> >>> } >>> >>> backend web3 { >>> >>> .host = "10.10.1.106"; >>> >>> .port = "80"; >>> >>> .connect_timeout = 45s; >>> >>> .first_byte_timeout = 45s; >>> >>> .between_bytes_timeout = 45s; >>> >>> .max_connections = 70; >>> >>> .probe = { >>> >>> .url = "/healthcheck.php"; >>> >>> .timeout = 5s; >>> >>> .interval = 30s; >>> >>> .window = 10; >>> >>> .threshold = 1; >>> >>> } >>> >>> } >>> >>> acl purge { >>> >>> "localhost"; >>> >>> "127.0.0.1"; >>> >>> "10.10.1.102"; >>> >>> "10.10.1.103"; >>> >>> } >>> >>> director www round-robin { >>> >>> { .backend = web1; } >>> >>> { .backend = web2; } >>> >>> { .backend = web3; } >>> >>> >>> } >>> >>> sub vcl_recv { >>> >>> set req.backend = www; >>> >>> set req.grace = 6h; >>> >>> if (!req.backend.healthy) { >>> >>> set req.grace = 24h; >>> >>> } >>> >>> set req.http.X-Forwarded-For = req.http.X-Forwarded-For ", " >>> client.ip; >>> >>> if (req.http.host ~ "^origin\.test(.+\.|)mywebsite\.com$") { >>> >>> return (pass); >>> >>> } >>> >>> if (req.http.host ~ ".*\.mywebsite.com|mywebsite.com") { >>> >>> /* allow (origin.)stage.m.mywebsite.com to be a separate host */ >>> >>> if (req.http.host != "stage.m.mywebsite.com") { >>> >>> set req.http.host = "stage.mywebsite.com"; >>> >>> } >>> >>> } else { >>> >>> return (pass); >>> >>> } >>> >>> if (req.request == "PURGE") { >>> >>> if (!client.ip ~ purge) { >>> >>> error 405 "Not allowed."; >>> >>> } >>> >>> return (lookup); >>> >>> } >>> >>> if (req.request != "GET" && >>> >>> req.request != "HEAD" && >>> >>> req.request != "PUT" && >>> >>> req.request != "POST" && >>> >>> req.request != "TRACE" && >>> >>> req.request != "OPTIONS" && >>> >>> req.request != "DELETE") { >>> >>> return (pipe); >>> >>> } >>> >>> if (req.request != "GET" && req.request != "HEAD") { >>> >>> return (pass); >>> >>> } >>> >>> if (req.url ~ "sites/all/modules/custom/bravo_ad/ads.html\?.*") { >>> >>> set req.url = "/sites/all/modules/custom/bravo_ad/ads.html"; >>> >>> } >>> >>> if (req.url ~ "eyeblaster/addineyeV2.html\?.*") { >>> >>> set req.url = "/eyeblaster/addineyeV2.html"; >>> >>> } >>> >>> if (req.url ~ >>> "ahah_helper\.php|bravo_points\.php|install\.php|update\.php|cron\.php|/json(:?\?.*)?$") >>> { >>> >>> return (pass); >>> >>> } >>> >>> if (req.http.Authorization) { >>> >>> return (pass); >>> >>> } >>> >>> if (req.url ~ "login" || req.url ~ "logout") { >>> >>> return (pass); >>> >>> } >>> >>> if (req.url ~ "^/admin/" || req.url ~ "^/node/add/") { >>> >>> return (pass); >>> >>> } >>> >>> if (req.http.Cache-Control ~ "no-cache") { >>> >>> // return (pass); >>> >>> } >>> >>> if (req.http.Cookie ~ >>> "(VARNISH|DRUPAL_UID|LOGGED_IN|SESS|_twitter_sess)") { >>> >>> set req.http.Cookie = regsuball(req.http.Cookie, >>> "(^|;\s*)(__[a-z]+|has_js)=[^;]*", ""); >>> >>> set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); >>> >>> } else { >>> >>> unset req.http.Cookie; >>> >>> } >>> >>> /* removed varnish cache backend logic */ >>> >>> if (req.restarts == 0) { >>> >>> set req.backend = www; >>> >>> } elsif (req.restarts >= 2) { >>> >>> return (pass); >>> >>> } >>> >>> if (req.restarts >= 2) { >>> >>> return (pass); >>> >>> } >>> >>> if (req.url ~ >>> "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") >>> { >>> >>> unset req.http.Accept-Encoding; >>> >>> } >>> >>> if (req.url ~ >>> "^/(sites/all/modules/mywebsite_admanager/includes/ads.php|doubleclick/DARTIframe.html)(\?.*|)$") >>> { >>> >>> set req.url = regsub(req.url, "\?.*$", ""); >>> >>> } >>> >>> if (req.http.Accept-Encoding ~ "gzip") { >>> >>> set req.http.Accept-Encoding = "gzip"; >>> >>> } elsif (req.http.Accept-Encoding ~ "deflate") { >>> >>> set req.http.Accept-Encoding = "deflate"; >>> >>> } else { >>> >>> unset req.http.Accept-Encoding; >>> >>> } >>> >>> return (lookup); >>> >>> } >>> >>> sub vcl_pipe { >>> >>> set bereq.http.connection = "close"; >>> >>> return (pipe); >>> >>> } >>> >>> sub vcl_pass { >>> >>> return (pass); >>> >>> } >>> >>> sub vcl_hash { >>> >>> set req.hash += req.url; >>> >>> set req.hash += req.http.host; >>> >>> if (req.http.Cookie ~ "VARNISH|DRUPAL_UID|LOGGED_IN") { >>> >>> set req.hash += req.http.Cookie; >>> >>> } >>> >>> return (hash); >>> >>> } >>> >>> sub vcl_hit { >>> >>> if (req.request == "PURGE") { >>> >>> set obj.ttl = 0s; >>> >>> error 200 "Purged."; >>> >>> } >>> >>> } >>> >>> sub vcl_fetch { >>> >>> if (beresp.status == 500) { >>> >>> set req.http.X-Varnish-Error = "1"; >>> >>> restart; >>> >>> } >>> >>> set beresp.grace = 6h; >>> >>> # Set a short circuit cache lifetime for resp codes above 302 >>> >>> if (beresp.status > 302) { >>> >>> set beresp.ttl = 60s; >>> >>> set beresp.http.Cache-Control = "max-age = 60"; >>> >>> } >>> >>> if (beresp.http.Edge-control ~ "no-store") { >>> >>> set beresp.http.storage = "1"; >>> >>> set beresp.cacheable = false; >>> >>> return (pass); >>> >>> } >>> >>> if (beresp.status >= 300 || !beresp.cacheable) { >>> >>> set beresp.http.Varnish-X-Cacheable = "Not Cacheable"; >>> >>> set beresp.http.storage = "1"; >>> >>> return (pass); >>> >>> } >>> >>> if (beresp.http.Set-Cookie) { >>> >>> return (pass); >>> >>> } >>> >>> if (beresp.cacheable) { >>> >>> unset beresp.http.expires; >>> >>> set beresp.ttl = 600s; >>> >>> set beresp.http.Cache-Control = "max-age = 600"; >>> >>> if (req.url ~ >>> "\.(ico|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|ICO|JPG|JPEG|PNG|GIF|GZ|TGZ|BZ2|TBZ|MP3|OOG|SWF)") >>> { >>> >>> set beresp.ttl = 43829m; >>> >>> set beresp.http.Cache-Control = "max-age = 1000000"; >>> >>> } >>> >>> } >>> >>> return (deliver); >>> >>> } >>> >>> >>> sub vcl_deliver { >>> >>> if (obj.hits > 0) { >>> >>> set resp.http.Varnish-X-Cache = "HIT"; >>> >>> set resp.http.Varnish-X-Cache-Hits = obj.hits; >>> >>> } else { >>> >>> set resp.http.Varnish-X-Cache = "MISS"; >>> >>> } >>> >>> return (deliver); >>> >>> } >>> >>> sub vcl_error { >>> >>> if (req.restarts == 0) { >>> >>> return (restart); >>> >>> } >>> >>> if (req.http.X-Varnish-Error != "1") { >>> >>> set req.http.X-Varnish-Error = "1"; >>> >>> return (restart); >>> >>> } >>> >>> } >>> >>> The only part that I omitted was the one pointing to the error >>> page. Can anyone offer any advice on how to troubleshoot this? >>> >>> I'm enclosing the full VCL in case that extra info is helpful. I didn't >>> omit much tho. >>> >>> Thank you! >>> >>> Tim >>> >>> -- >>> GPG me!! >>> >>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B >>> >>> >> >> >> -- >> GPG me!! >> >> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> >> >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: varnish-ping.png Type: image/png Size: 128851 bytes Desc: not available URL: From theistian at gmx.com Wed May 14 09:15:47 2014 From: theistian at gmx.com (Carlos =?iso-8859-1?Q?Pe=F1as?=) Date: Wed, 14 May 2014 11:15:47 +0200 Subject: Migrating v3 to v4: How to efectively detect a cache miss in VCL? Message-ID: <20140514091546.GA4451@tydirium.the-staging.com> Hi. I'm starting the tests to migrate to v4 and I have an issue setting headers to detect the HIT/MISS. In v3 I was using the method described in https://www.varnish-cache.org/trac/wiki/VCLExampleHitMissHeader sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } } But now in varnish 4 when an url is banned the Age is reseted but obj.hits seems to remain the same I've found this excerpt indicating the change of behaviour in obj.hits https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html#obj-is-now-read-only The bug indicated was closed indicating that obj.hits = 0 no longer indicates a cache MISS So. How and where I can detect the handling and set a response header to indicate a real HIT/MISS? Thanks -- Carlos Pe?as San Jos? carlos at adoptales.es From fishthirteen at gmail.com Wed May 14 16:40:15 2014 From: fishthirteen at gmail.com (Thirteen Fish) Date: Thu, 15 May 2014 00:40:15 +0800 Subject: Why my varnish create different cache object for different client? Message-ID: Every one, I'm a newbie for varnish and I need your help. My varnish has an strange problem. It create different hash for same url for different client, and this result in any new user which access my site can't hit the cache. >From the varnish log, I found the varnish hit different object though the hash data is same. Following are the logs. *Varnish Log From Client 1 (192.168.66.81)* 1 14 StatSess c 192.168.66.81 49278 0 1 0 0 0 0 0 0 2 11 SessionOpen c 192.168.66.81 49300 :80 3 11 ReqStart c 192.168.66.81 49300 1750481507 4 11 RxRequest c GET 5 11 RxURL c /Mainpage 6 11 RxProtocol c HTTP/1.1 7 11 RxHeader c Host: zh.moegirl.org 8 11 RxHeader c Connection: keep-alive 9 11 RxHeader c Cache-Control: max-age=0 10 11 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 11 11 RxHeader c User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36 12 11 RxHeader c Accept-Encoding: gzip,deflate,sdch 13 11 RxHeader c Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4 14 11 RxHeader c Cookie: __utma=1.51232645.1400082743.1400082743.1400082743.1; __utmb=1.1.10.1400082743; __utmc=1; __utmz=1.1400082743.1.1. utmcsr=(direct)|utmccn=(direct)|utmcmd=( 15 none); __gads=ID=d1f7dc9d52cd4a78:T=1400082743:S=ALNI_MbXhSNK0VtcUY7M9mjv8nanysdcbg 16 11 VCL_call c recv lookup 17 11 VCL_call c hash 18 11 Hash c /Mainpage 19 11 Hash c zh.moegirl.org 20 11 VCL_return c hash 21 11 Hit c 1750481502 22 11 VCL_call c hit deliver 23 11 VCL_call c deliver deliver 24 11 TxProtocol c HTTP/1.1 25 11 TxStatus c 200 26 11 TxResponse c OK 27 11 TxHeader c Server: nginx/1.6.0 28 11 TxHeader c Content-Type: text/html; charset=UTF-8 29 11 TxHeader c Vary: Accept-Encoding, Accept-Encoding, Cookie, Accept-Language 30 11 TxHeader c X-Content-Type-Options: nosniff 31 11 TxHeader c Content-language: zh 32 11 TxHeader c Cache-Control: s-maxage=2678400, must-revalidate, max-age=0 33 11 TxHeader c Last-Modified: Mon, 12 May 2014 20:01:11 GMT 34 11 TxHeader c Content-Encoding: gzip 35 11 TxHeader c X-Varnish: 1594679620 36 11 TxHeader c Via: 1.1 varnish 37 11 TxHeader c X-Cache: MISS 38 11 TxHeader c host: zh.moegirl.org 39 11 TxHeader c Content-Length: 14977 40 11 TxHeader c Accept-Ranges: bytes 41 11 TxHeader c Date: Wed, 14 May 2014 15:52:33 GMT 42 11 TxHeader c X-Varnish: 1750481507 1750481502 43 11 TxHeader c Age: 180 44 11 TxHeader c Via: 1.1 varnish 45 11 TxHeader c Connection: keep-alive 46 11 TxHeader c v-Cache: HIT 47 11 Length c 14977 48 11 ReqEnd c 1750481507 1400082753.326334476 1400082753.326504469 0.000313997 0.000061512 0.000108480 *Varnish Log From Client 2 (192.168.66.106)* 1 11 SessionOpen c 192.168.66.106 34154 :80 2 11 ReqStart c 192.168.66.106 34154 1750481508 3 11 RxRequest c GET 4 11 RxURL c /Mainpage 5 11 RxProtocol c HTTP/1.1 6 11 RxHeader c Host: zh.moegirl.org 7 11 RxHeader c Connection: keep-alive 8 11 RxHeader c Cache-Control: max-age=0 9 11 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 10 11 RxHeader c User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 Safari/537.36 11 11 RxHeader c Accept-Encoding: gzip,deflate,sdch 12 11 RxHeader c Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4,en-US;q=0.2,en-GB;q=0.2 13 11 RxHeader c Cookie: __gads=ID=b048dccb69e9da93:T=1399163153:S=ALNI_Mao_IUR1acm9tlz_9E4C5DuSDZ98g; wikiEditor-0-booklet-characters-page=latin; wikiEditor-0-toolbar- section=advanced; moegirlSSOUserName=Fishthirteen; moegirlSSO_session=bfmb7k0dadsau1dalp5ou53uc6; moegir 14 11 VCL_call c recv lookup 15 11 VCL_call c hash 16 11 Hash c /Mainpage 17 11 Hash c zh.moegirl.org 18 11 VCL_return c hash 19 11 Hit c 1750481474 20 11 VCL_call c hit deliver 21 11 VCL_call c deliver deliver 22 11 TxProtocol c HTTP/1.1 23 11 TxStatus c 200 24 11 TxResponse c OK 25 11 TxHeader c Server: nginx/1.6.0 26 11 TxHeader c Content-Type: text/html; charset=UTF-8 27 11 TxHeader c Vary: Accept-Encoding, Accept-Encoding, Cookie, Accept-Language 28 11 TxHeader c X-Content-Type-Options: nosniff 29 11 TxHeader c Content-language: zh 30 11 TxHeader c Cache-Control: s-maxage=2678400, must-revalidate, max-age=0 31 11 TxHeader c Last-Modified: Mon, 12 May 2014 20:01:11 GMT 32 11 TxHeader c Content-Encoding: gzip 33 11 TxHeader c X-Varnish: 1594676989 34 11 TxHeader c Via: 1.1 varnish 35 11 TxHeader c X-Cache: MISS 36 11 TxHeader c host: zh.moegirl.org 37 11 TxHeader c Content-Length: 14975 38 11 TxHeader c Accept-Ranges: bytes 39 11 TxHeader c Date: Wed, 14 May 2014 15:53:18 GMT 40 11 TxHeader c X-Varnish: 1750481508 1750481474 41 11 TxHeader c Age: 514 42 11 TxHeader c Via: 1.1 varnish 43 11 TxHeader c Connection: keep-alive 44 11 TxHeader c v-Cache: HIT 45 11 Length c 14975 46 11 ReqEnd c 1750481508 1400082798.821015596 1400082798.821227551 0.000247717 0.000054121 0.000157833 *You can see the hash keys are same (**/Mainpage + **zh.moegirl.org ) but the hit object is different(1750481502 and 1750481474)* *And following is my default.vcl*. I just change a little from the default vcl settings. backend default { .host = "zh.moegirl.org"; .port = "80"; } # # Below is a commented-out copy of the default VCL logic. If you # redefine any of these subroutines, the built-in logic will be # appended to your code. sub vcl_recv { if (req.restarts == 0) { if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip; } else { set req.http.X-Forwarded-For = client.ip; } } if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { /* Non-RFC2616 or CONNECT which is weird. */ return (pipe); } if (req.request != "GET" && req.request != "HEAD") { /* We only deal with GET and HEAD by default */ return (pass); } // if (req.http.Authorization || req.http.Cookie) { // /* Not cacheable by default */ // //return (pass); // } if (req.http.Cookie ~ "UserID") { } else { unset req.http.Cookie; } return (lookup); } sub vcl_pipe { # Note that only the first request to the backend will have # X-Forwarded-For set. If you use X-Forwarded-For and want to # have it set for all requests, make sure to have: # set bereq.http.connection = "close"; # here. It is not set by default as it might break some broken web # applications, like IIS with NTLM authentication. return (pipe); } sub vcl_pass { return (pass); } sub vcl_hash { hash_data(req.url); if (req.http.host) { hash_data(req.http.host); } else { hash_data(server.ip); } return (hash); } sub vcl_hit { return (deliver); } sub vcl_miss { return (fetch); } sub vcl_fetch { if (beresp.http.host != req.http.host) { set beresp.http.host = req.http.host; } //set beresp.http.host = "zh.moegirl.org:6081"; if (beresp.ttl <= 0s || beresp.http.Set-Cookie || beresp.http.Vary == "*") { /* * Mark as "Hit-For-Pass" for the next 2 minutes */ set beresp.ttl = 120 s; return (hit_for_pass); } return (deliver); } sub vcl_deliver { if (obj.hits > 0) { set resp.http.v-Cache = "HIT"; } else { set resp.http.v_Cache = "MISS"; } return (deliver); } sub vcl_error { set obj.http.Content-Type = "text/html; charset=utf-8"; set obj.http.Retry-After = "5"; synthetic {" "} + obj.status + " " + obj.response + {"

Error "} + obj.status + " " + obj.response + {"

"} + obj.response + {"

Guru Meditation:

XID: "} + req.xid + {"

Varnish cache server

"}; return (deliver); } sub vcl_init { return (ok); } sub vcl_fini { return (ok); } *And my enviroment* Varnish Version: 3.0.5 OS: Ubuntu 14.04 LTS Browers: Chromium 34 (One is in Linux(Debain Testing), and other is in Windows 8) Besides, please forgive my pool English. Thank you very much! Fish Thirteen -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugues at betabrand.com Wed May 14 21:44:53 2014 From: hugues at betabrand.com (Hugues Alary) Date: Wed, 14 May 2014 14:44:53 -0700 Subject: Weirdness and graceful restart Message-ID: Hi everyone, I've been having a bug for the past few months where my varnishadm is outputing wrong data. For example, typing: $ varnishadm backend.list available 0 boot available 0 63952152-25bd-4ee7-b2f9-aa0244a05ccf available 0 622f3e24-019e-48a3-8658-b310119947f4 available 0 fbd3fbc6-3a74-49a3-aeeb-100028da0ee6 available 0 0a37ec01-b01f-495f-9b0b-a95252080637 available 0 bd7624b2-3751-49fe-a745-3eadcad61289 available 0 29e08a95-56bc-4bfc-8985-a95e1c5db2de available 0 319ed00f-a10f-4077-91e8-c0245f90f6cd available 0 eaf3a4fe-c403-4e45-a6c8-32b81a1ddb68 available 0 c9cf84fa-447e-46ab-baa5-f165f21ba793 available 0 377cdfc8-ffce-4a6b-a361-c5b4b522edc3 available 0 9d2de965-1770-4859-8ea9-fb3886116a42 available 0 blogfixtmp available 0 blog available 0 blog1 available 0 t2 available 0 22850af6-7199-43ec-9730-5cf03cbcf94b available 0 t4 available 0 t5 available 0 bbd996f1-c502-4977-88dd-b59985a31878 available 0 t10 available 0 t11 available 0 t12 available 0 t13 available 0 df946b95-2dee-407e-9434-92b9a33cbb59 available 0 thugues available 0 t20 available 0 jared available 0 hugues available 0 hugues-2 available 0 hugues-3 available 0 hugues-4 available 0 redis-bug available 0 f243afbb-ae48-4068-a702-5cf497fb53cb available 0 hugues-random available 0 redisbug available 0 redisbug2 active 32 redisbug3 Typing it again would return something else, and so forth and so on. It hasn't bothered me too much since I eventually get what I want, and everything works, it's just the output that is messed up. This never fixed itself, since varnish is super stable (85 days up since last restart) and I haven't restarted it. Now, it so happen that I really need to restart varnish, and I'm really excited about doing it because it will fix the varnishadm problems. *My question being: is there a way to restart varnish, without interrupting current incoming requests?* Thanks for your help! -Hugues ps: in case you're interested in the varnishadm bug, here's the useful information: Debian 7.3 Linux 3.10.23-xxxx-grs-ipv6-64 #1 SMP Mon Dec 9 19:06:18 CET 2013 x86_64 GNU/Linux varnishd (varnish-3.0.5 revision 1a89b1f) *How did the varnishadm bug happen? * One day I typed, on my busy varnish: varnishadm ban.list After waiting for a while, I got some output. Since that day, varnishadm output is wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at talkunafraid.co.uk Thu May 15 11:41:45 2014 From: james at talkunafraid.co.uk (James Harrison) Date: Thu, 15 May 2014 12:41:45 +0100 Subject: Threads in 4.0 Message-ID: <5374A7F9.6010404@talkunafraid.co.uk> Hi, So I migrated a site dealing with a quite simple Varnish config (basically caching images and static content, passing through dynamic requests with no modifications etc) last week. Since then I've had to restart varnish twice due to what looks like a thread pool leak. Varnish is configured with a max thread count of 1000 - the other thread options are defaults. With all defaults the problem still occurs. This is a Debian Wheezy system using the Varnish packages (ie not system packages). varnishstat shows MAIN.threads as 500 and has ~7.5k, 8k for created/destroyed (11 for limited). Varnish has served a TB of content since restart a day ago in this state. `ps auxH | grep varnish | wc -l` shows varnish has 7508 threads/processes running. This graph shows the rapid increase in running threads - I restarted varnish with the lower pool limit at the end of the 13th: https://i.imgur.com/488IT7z.png Any ideas? -- Cheers, James From mbubanale at sapient.com Thu May 15 11:42:39 2014 From: mbubanale at sapient.com (Mahesh Narsappa Bubanale) Date: Thu, 15 May 2014 11:42:39 +0000 Subject: Need step by step document for windows executions Message-ID: <1BBA504926243F458E98D3E34698CB45397A4DC7@BANGMAIL01.sapient.com> Hi, I am new to Varnish and doing some demo project. I need very informative document to execute Varnish on Windows and also need more information to execute caching mechanism on my application. Regards, Mahesh Bubanale -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi.boukelmoune at zenika.com Thu May 15 13:19:12 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Thu, 15 May 2014 15:19:12 +0200 Subject: Threads in 4.0 In-Reply-To: <5374A7F9.6010404@talkunafraid.co.uk> References: <5374A7F9.6010404@talkunafraid.co.uk> Message-ID: On Thu, May 15, 2014 at 1:41 PM, James Harrison wrote: > Hi, > > So I migrated a site dealing with a quite simple Varnish config > (basically caching images and static content, passing through dynamic > requests with no modifications etc) last week. Since then I've had to > restart varnish twice due to what looks like a thread pool leak. > > Varnish is configured with a max thread count of 1000 - the other > thread options are defaults. With all defaults the problem still > occurs. This is a Debian Wheezy system using the Varnish packages (ie > not system packages). > > varnishstat shows MAIN.threads as 500 and has ~7.5k, 8k for > created/destroyed (11 for limited). Varnish has served a TB of content > since restart a day ago in this state. > > `ps auxH | grep varnish | wc -l` shows varnish has 7508 > threads/processes running. > > This graph shows the rapid increase in running threads - I restarted > varnish with the lower pool limit at the end of the 13th: > https://i.imgur.com/488IT7z.png > > Any ideas? Hi, I remember this: https://www.varnish-cache.org/lists/pipermail/varnish-commit/2014-May/011395.html Dridi > -- > Cheers, > James > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From perbu at varnish-software.com Thu May 15 13:30:48 2014 From: perbu at varnish-software.com (Per Buer) Date: Thu, 15 May 2014 15:30:48 +0200 Subject: System can't take more than 5k req /sec In-Reply-To: References: <535ebc159bd10_5163583282c5656c@a4-wakko5.mail> <9f0fd75294054cccb1ca9b759443d33a@AM3PR02MB178.eurprd02.prod.outlook.com> Message-ID: Those are probably fine on a LAN for benchmarking but they will not work on the internet. Per. On Tue, May 13, 2014 at 3:31 PM, Jason Price wrote: > Private message requesting TCP tuning. For the record, these are > draft numbers and very tightly tied to our use case, so they should > not be copied blindly. > > somaxconn is 512 > txqueuelen is 5000 > netdev_max_backlog is 5000 > tcp_max_syn_backlog is 4096 > enable tcp_tw_recycle > enable tcp_tw_reuse > > > > > On Tue, May 13, 2014 at 6:45 AM, ??????? ????????????? > wrote: > > Could you please give us some more information about your > > TCP tuning? > > Regards > > Yiannis > > > > -----Original Message----- > > From: varnish-misc-bounces+gkaragiannidis=dolnet.gr at varnish-cache.org[mailto: > varnish-misc-bounces+gkaragiannidis=dolnet.gr at varnish-cache.org] On > Behalf Of Jason Price > > Sent: Tuesday, May 13, 2014 12:33 AM > > To: Norberto Meijome > > Cc: varnish-misc at varnish-cache.org > > Subject: Re: System can't take more than 5k req /sec > > > > So, through some TCP tuning we've been able to get to 20k/s. Though I > needed to get up to 8k threads per pool. > > > > Many docs say 'Don't go more than 4k threads'. Can someone explain > that? Anyone have experience with 8-10k threads? > > > > --Jason > > > > On Tue, Apr 29, 2014 at 10:41 PM, Jason Price wrote: > >> On Tuesday, April 29, 2014, Norberto Meijome wrote: > >>> > >>> Have you ruled out AWS limits? Putting varnish aside for a minute, > >>> can you handle 5k/sec TCP conns with something like nginx +static > files.? > >> > >> This is an excellent question. I'll see what kind of answer I'll get > to it. > >> > >> -Jason > > > > _______________________________________________ > > varnish-misc mailing list > > varnish-misc at varnish-cache.org > > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Thu May 15 14:36:48 2014 From: perbu at varnish-software.com (Per Buer) Date: Thu, 15 May 2014 16:36:48 +0200 Subject: Why my varnish create different cache object for different client? In-Reply-To: References: Message-ID: Hi Mr Fish. On Wed, May 14, 2014 at 6:40 PM, Thirteen Fish wrote: > Every one, I'm a newbie for varnish and I need your help. > > My varnish has an strange problem. It create different hash for same url > for different client, and this result in any new user which access my site > can't hit the cache. > > From the varnish log, I found the varnish hit different object though the > hash data is same. Following are the logs. > Thanks. The reason Varnish is doing this is because the backend asks it to do so. Check out this line: Vary: Accept-Encoding, Accept-Encoding, Cookie, Accept-Language If you google "http vary" you'll find some nice explanations on how it works. With that Vary line you'll never get a high hit rate. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From japrice at gmail.com Thu May 15 17:17:01 2014 From: japrice at gmail.com (Jason Price) Date: Thu, 15 May 2014 13:17:01 -0400 Subject: System can't take more than 5k req /sec In-Reply-To: References: <535ebc159bd10_5163583282c5656c@a4-wakko5.mail> <9f0fd75294054cccb1ca9b759443d33a@AM3PR02MB178.eurprd02.prod.outlook.com> Message-ID: Please expound. (in our use case, our backends are all 'local' within the AWS regions, with less than 1 millisecond RTT (sometimes way less).) Our frontend systems are ELBs with similar response times. That's a rough approximation of 'LAN' usage, unless I'm missing something. --Jason On Thu, May 15, 2014 at 9:30 AM, Per Buer wrote: > Those are probably fine on a LAN for benchmarking but they will not work > on the internet. > > Per. > > > On Tue, May 13, 2014 at 3:31 PM, Jason Price wrote: > >> Private message requesting TCP tuning. For the record, these are >> draft numbers and very tightly tied to our use case, so they should >> not be copied blindly. >> >> somaxconn is 512 >> txqueuelen is 5000 >> netdev_max_backlog is 5000 >> tcp_max_syn_backlog is 4096 >> enable tcp_tw_recycle >> enable tcp_tw_reuse >> >> >> >> >> On Tue, May 13, 2014 at 6:45 AM, ??????? ????????????? >> wrote: >> > Could you please give us some more information about your >> > TCP tuning? >> > Regards >> > Yiannis >> > >> > -----Original Message----- >> > From: varnish-misc-bounces+gkaragiannidis=dolnet.gr at varnish-cache.org[mailto: >> varnish-misc-bounces+gkaragiannidis=dolnet.gr at varnish-cache.org] On >> Behalf Of Jason Price >> > Sent: Tuesday, May 13, 2014 12:33 AM >> > To: Norberto Meijome >> > Cc: varnish-misc at varnish-cache.org >> > Subject: Re: System can't take more than 5k req /sec >> > >> > So, through some TCP tuning we've been able to get to 20k/s. Though I >> needed to get up to 8k threads per pool. >> > >> > Many docs say 'Don't go more than 4k threads'. Can someone explain >> that? Anyone have experience with 8-10k threads? >> > >> > --Jason >> > >> > On Tue, Apr 29, 2014 at 10:41 PM, Jason Price >> wrote: >> >> On Tuesday, April 29, 2014, Norberto Meijome wrote: >> >>> >> >>> Have you ruled out AWS limits? Putting varnish aside for a minute, >> >>> can you handle 5k/sec TCP conns with something like nginx +static >> files.? >> >> >> >> This is an excellent question. I'll see what kind of answer I'll get >> to it. >> >> >> >> -Jason >> > >> > _______________________________________________ >> > varnish-misc mailing list >> > varnish-misc at varnish-cache.org >> > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > > > -- > *Per Buer* > CTO | Varnish Software > Phone: +47 958 39 117 | Skype: per.buer > We Make Websites Fly! > > Winner of the Red Herring Top 100 Global Award 2013 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Thu May 15 17:48:15 2014 From: perbu at varnish-software.com (Per Buer) Date: Thu, 15 May 2014 19:48:15 +0200 Subject: System can't take more than 5k req /sec In-Reply-To: References: <535ebc159bd10_5163583282c5656c@a4-wakko5.mail> <9f0fd75294054cccb1ca9b759443d33a@AM3PR02MB178.eurprd02.prod.outlook.com> Message-ID: reuse/recycle breaks clients on NATed network. I think reuse by itself is dodgy, but generally works OK. recycle is pretty bad. On Thu, May 15, 2014 at 7:17 PM, Jason Price wrote: > Please expound. > > (in our use case, our backends are all 'local' within the AWS regions, > with less than 1 millisecond RTT (sometimes way less).) > > Our frontend systems are ELBs with similar response times. > > That's a rough approximation of 'LAN' usage, unless I'm missing something. > > --Jason > > > On Thu, May 15, 2014 at 9:30 AM, Per Buer wrote: > >> Those are probably fine on a LAN for benchmarking but they will not work >> on the internet. >> >> Per. >> >> >> On Tue, May 13, 2014 at 3:31 PM, Jason Price wrote: >> >>> Private message requesting TCP tuning. For the record, these are >>> draft numbers and very tightly tied to our use case, so they should >>> not be copied blindly. >>> >>> somaxconn is 512 >>> txqueuelen is 5000 >>> netdev_max_backlog is 5000 >>> tcp_max_syn_backlog is 4096 >>> enable tcp_tw_recycle >>> enable tcp_tw_reuse >>> >>> >>> >>> >>> On Tue, May 13, 2014 at 6:45 AM, ??????? ????????????? >>> wrote: >>> > Could you please give us some more information about your >>> > TCP tuning? >>> > Regards >>> > Yiannis >>> > >>> > -----Original Message----- >>> > From: varnish-misc-bounces+gkaragiannidis=dolnet.gr at varnish-cache.org[mailto: >>> varnish-misc-bounces+gkaragiannidis=dolnet.gr at varnish-cache.org] On >>> Behalf Of Jason Price >>> > Sent: Tuesday, May 13, 2014 12:33 AM >>> > To: Norberto Meijome >>> > Cc: varnish-misc at varnish-cache.org >>> > Subject: Re: System can't take more than 5k req /sec >>> > >>> > So, through some TCP tuning we've been able to get to 20k/s. Though I >>> needed to get up to 8k threads per pool. >>> > >>> > Many docs say 'Don't go more than 4k threads'. Can someone explain >>> that? Anyone have experience with 8-10k threads? >>> > >>> > --Jason >>> > >>> > On Tue, Apr 29, 2014 at 10:41 PM, Jason Price >>> wrote: >>> >> On Tuesday, April 29, 2014, Norberto Meijome >>> wrote: >>> >>> >>> >>> Have you ruled out AWS limits? Putting varnish aside for a minute, >>> >>> can you handle 5k/sec TCP conns with something like nginx +static >>> files.? >>> >> >>> >> This is an excellent question. I'll see what kind of answer I'll get >>> to it. >>> >> >>> >> -Jason >>> > >>> > _______________________________________________ >>> > varnish-misc mailing list >>> > varnish-misc at varnish-cache.org >>> > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>> >>> _______________________________________________ >>> varnish-misc mailing list >>> varnish-misc at varnish-cache.org >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>> >> >> >> >> -- >> *Per Buer* >> CTO | Varnish Software >> Phone: +47 958 39 117 | Skype: per.buer >> We Make Websites Fly! >> >> Winner of the Red Herring Top 100 Global Award 2013 >> >> >> > -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From devel at jasonwoods.me.uk Fri May 16 16:16:35 2014 From: devel at jasonwoods.me.uk (Jason Woods) Date: Fri, 16 May 2014 17:16:35 +0100 Subject: Signed RPM Packages Message-ID: <46085FDC-43C6-4DD0-A15B-8057194A4D43@jasonwoods.me.uk> Hi, I followed installation at: https://www.varnish-cache.org/installation/redhat But noticed that the GPG signature checking of the RPMs was not enabled, and the RPMs were transferred over plaintext HTTP! I did re-enabled the signature checking but it seems none of the packages are actually signed. Are there plans to sign the packages? As I'm unable to use them in this state. I did find references to "signing corrupts the packages" - maybe I could offer help looking into the problem? It would be really useful to have them signed. NB: It would be good for the installation page mentioned to also state the packages are not signed and transferred via HTTP. Just so one can make a judgement call, as at the moment it could easily be missed. Thanks! Jason From perbu at varnish-software.com Fri May 16 17:55:30 2014 From: perbu at varnish-software.com (Per Buer) Date: Fri, 16 May 2014 19:55:30 +0200 Subject: Signed RPM Packages In-Reply-To: <46085FDC-43C6-4DD0-A15B-8057194A4D43@jasonwoods.me.uk> References: <46085FDC-43C6-4DD0-A15B-8057194A4D43@jasonwoods.me.uk> Message-ID: Hi Jason, On Fri, May 16, 2014 at 6:16 PM, Jason Woods wrote: > Hi, > > I followed installation at: > https://www.varnish-cache.org/installation/redhat > > But noticed that the GPG signature checking of the RPMs was not enabled, > and the RPMs were transferred over plaintext HTTP! > I did re-enabled the signature checking but it seems none of the packages > are actually signed. > The repo does talk HTTPS at this point so you can switch to SSL, giving you transport level security at least. Are there plans to sign the packages? As I'm unable to use them in this > state. > I did find references to "signing corrupts the packages" - maybe I could > offer help looking into the problem? It would be really useful to have them > signed. > Last time it was enabled we have spurious corruption of the whole RPM database when the packages where installed. Nobody ever managed to actually track this down and we left out the signing. Lasse might have more information wrt to the state of the packages right now. I know he has been working on the RPMs quite a bit lately. Per. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at talkunafraid.co.uk Fri May 16 20:24:18 2014 From: james at talkunafraid.co.uk (James Harrison) Date: Fri, 16 May 2014 21:24:18 +0100 Subject: Threads in 4.0 In-Reply-To: References: <5374A7F9.6010404@talkunafraid.co.uk> Message-ID: <537673F2.8090701@talkunafraid.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/05/2014 14:19, Dridi Boukelmoune wrote: > > I remember this: > https://www.varnish-cache.org/lists/pipermail/varnish-commit/2014-May/011395.html > > Good to know. There's more than just that one bug, though - just had an hourlong site outage due to varnish's child just up and dying and not being restarted. Wouldn't know where to look for debug output - restarted the parent and it worked again for about 3 minutes and then the child didn't die but it did stop servicing requests. New requests would be accepted, and held open, but nothing happened subsequently. Just downgraded to 3.0 and everything's working again. Persistent storage is a nice-to-have to avoid cold caches after restarts/crashes, but 4.0 clearly needs some work before it goes anywhere near production. Happy to help test things and kick the tyres/provide more info if that'd be of use... - -- Cheers, James Harrison -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJTdnPyAAoJENTyYHL8dmp9DJEP/1fWCfo6hLnDAl5WQWg3tmUr iAYOuJGe0nHOgVquXbZqDIkv4Se5LRBRPBGvVs0ywfErKmfZ0CF7S7SiyDtGMvK5 xdLUEjqCs6qjE6wcPi8JILfTJWqAwIAsWb+bG9ABmbKyhz5jP1A3eZv6moVB8i6U TUJA9nU8ksmqGF/wDlqcWpqeCMLEJcWKO8wQ2y+No7ZhIkX2ItSzyhYZ75CPLxWN 9UFY+ND8FaeLFU+TOB2iS7gubJHMzh2AnzjGNRWSMt4ZVsZHJW9U22EbmJlBMuDC jrH7wSR4HbqjMaizh+eMIgXhCON0uB1PwMvedzrH2R1qwv+38NGjp+eSYTiFi+cm bhqT1MPLxT43aWb32jzIHrYIxrxpX/V2ZTc7N1GoqdoKF0lLZ/JD87qfNa2m69w/ rmnPnAM51rGgAdzoRD2N6Eja/yReMtO8C7BGv0SaA5VLv0HOhlMO5uNkd2E53ulE Osxa9ddlDIMEylDs9d0PwYw9nhtsWLp1g6AVFkC9ktjFuN20+ZApKmsf1BR7a0EQ X1jjcqFPAcxteDn0A2sO+D7L9xaE49WYqtLo6EridnzfHDmAjPk0WY53CP1iAvaX C8A3KNwraa9G878VJDKDMwikbPO0BWw05J6EGgKAPs5ScRdaT4eNc4/71yNBR9O7 6pooJ7BI3OsxxiMn0+jU =wpgb -----END PGP SIGNATURE----- From apj at mutt.dk Mon May 19 06:54:34 2014 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Mon, 19 May 2014 08:54:34 +0200 Subject: Threads in 4.0 In-Reply-To: <537673F2.8090701@talkunafraid.co.uk> References: <5374A7F9.6010404@talkunafraid.co.uk> <537673F2.8090701@talkunafraid.co.uk> Message-ID: <20140519065434.GV19870@nerd.dk> On Fri, May 16, 2014 at 09:24:18PM +0100, James Harrison wrote: > > > Good to know. There's more than just that one bug, though - just had > an hourlong site outage due to varnish's child just up and dying and > not being restarted. Wouldn't know where to look for debug output - > restarted the parent and it worked again for about 3 minutes and then > the child didn't die but it did stop servicing requests. New requests > would be accepted, and held open, but nothing happened subsequently. > > Just downgraded to 3.0 and everything's working again. Persistent > storage is a nice-to-have to avoid cold caches after restarts/crashes, > but 4.0 clearly needs some work before it goes anywhere near production. It sounds like you've upgraded to get persistent? Persistent is still experimental, just as it was in 3.0. -- Andreas From perbu at varnish-software.com Mon May 19 07:09:58 2014 From: perbu at varnish-software.com (Per Buer) Date: Mon, 19 May 2014 09:09:58 +0200 Subject: Threads in 4.0 In-Reply-To: <20140519065434.GV19870@nerd.dk> References: <5374A7F9.6010404@talkunafraid.co.uk> <537673F2.8090701@talkunafraid.co.uk> <20140519065434.GV19870@nerd.dk> Message-ID: Hi, On Mon, May 19, 2014 at 8:54 AM, Andreas Plesner Jacobsen wrote: > On Fri, May 16, 2014 at 09:24:18PM +0100, James Harrison wrote: > > > > > Good to know. There's more than just that one bug, though - just had > > an hourlong site outage due to varnish's child just up and dying and > > not being restarted. Wouldn't know where to look for debug output - > > restarted the parent and it worked again for about 3 minutes and then > > the child didn't die but it did stop servicing requests. New requests > > would be accepted, and held open, but nothing happened subsequently. > > > > Just downgraded to 3.0 and everything's working again. Persistent > > storage is a nice-to-have to avoid cold caches after restarts/crashes, > > but 4.0 clearly needs some work before it goes anywhere near production. > > It sounds like you've upgraded to get persistent? Persistent is still > experimental, just as it was in 3.0. > Experimental is misleading, it makes it sound like the code has a future. I think the persistence code is still there because nobody has bothered disabling it yet. There is no work being done on the persistent. I doubt someone will pick it up. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From apj at mutt.dk Mon May 19 07:38:28 2014 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Mon, 19 May 2014 09:38:28 +0200 Subject: Threads in 4.0 In-Reply-To: References: <5374A7F9.6010404@talkunafraid.co.uk> <537673F2.8090701@talkunafraid.co.uk> <20140519065434.GV19870@nerd.dk> Message-ID: <20140519073828.GW19870@nerd.dk> On Mon, May 19, 2014 at 09:09:58AM +0200, Per Buer wrote: > > > > > > Just downgraded to 3.0 and everything's working again. Persistent > > > storage is a nice-to-have to avoid cold caches after restarts/crashes, > > > but 4.0 clearly needs some work before it goes anywhere near production. > > > > It sounds like you've upgraded to get persistent? Persistent is still > > experimental, just as it was in 3.0. > > > > Experimental is misleading, it makes it sound like the code has a future. I > think the persistence code is still there because nobody has bothered > disabling it yet. > > There is no work being done on the persistent. I doubt someone will pick it > up. True. My point was mostly that I would expect persistent to act just as bad in 3.0 as in 4.0, so it should never be the reason for upgrading. -- Andreas From slink at schokola.de Mon May 19 11:00:05 2014 From: slink at schokola.de (Nils Goroll) Date: Mon, 19 May 2014 13:00:05 +0200 Subject: survey: known clients which can't handle Chunked Transfer Coding Message-ID: <5379E435.9030204@schokola.de> Working on https://www.varnish-cache.org/trac/ticket/1506 it would be helpful to get to know more about clients which send HTTP/1.1 requests but fail to handle chunked responses or require Content-Length for other reasons. Some Background: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand. So we are actually querying here for clients which _violate_ rfc2616, but which are important in real live nonetheless. Please do not update the ticket with this information, personal email to me is sufficient. I will post the results. Nils From james at talkunafraid.co.uk Mon May 19 14:29:37 2014 From: james at talkunafraid.co.uk (James Harrison) Date: Mon, 19 May 2014 15:29:37 +0100 Subject: Threads in 4.0 In-Reply-To: <20140519065434.GV19870@nerd.dk> References: <5374A7F9.6010404@talkunafraid.co.uk> <537673F2.8090701@talkunafraid.co.uk> <20140519065434.GV19870@nerd.dk> Message-ID: <537A1551.5040206@talkunafraid.co.uk> On 19/05/14 07:54, Andreas Plesner Jacobsen wrote: > It sounds like you've upgraded to get persistent? Persistent is > still experimental, just as it was in 3.0. Upgraded to be on the current latest stable maintained build, not to use persistent. I like to do upgrades in a controlled manner while the old version is still viable so finding bugs isn't catastrophic! Persistent I only switched to when it was clear to work around the thread issue I was going to be restarting the thing a lot till a fix got issued/I had time to build from source to see if that commit fixed it. If the persistent storage is broken/dodgy to the extent it was causing the whole thing to lock up and die then it shouldn't be in the release imho. Experimental is certainly the wrong wording - deprecated, perhaps? I'll try again when >4.0.0 is out with a fix for the thread pool issue and see how things work using the usual transient memory store. -- Cheers, James From phk at phk.freebsd.dk Mon May 19 21:26:49 2014 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 19 May 2014 21:26:49 +0000 Subject: Future of -spersistent (was: Threads in 4.0) In-Reply-To: References: <5374A7F9.6010404@talkunafraid.co.uk> <537673F2.8090701@talkunafraid.co.uk> <20140519065434.GV19870@nerd.dk> Message-ID: <49397.1400534809@critter.freebsd.dk> In message , Per Buer writes: >> > storage is a nice-to-have to avoid cold caches after restarts/crashes, >> > but 4.0 clearly needs some work before it goes anywhere near production. >> >> It sounds like you've upgraded to get persistent? Persistent is still >> experimental, just as it was in 3.0. > >Experimental is misleading, it makes it sound like the code has a future. I >think the persistence code is still there because nobody has bothered >disabling it yet. > >There is no work being done on the persistent. I doubt someone will pick it >up. There's no formal decision on the future of -spersistent, but if Varnish-Software has (also) given up on it, maybe we should make that decision right now and drop -spersistent before 4.0.1 ? Any input ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From numard at gmail.com Mon May 19 22:39:33 2014 From: numard at gmail.com (Norberto Meijome) Date: Tue, 20 May 2014 08:39:33 +1000 Subject: Threads in 4.0 In-Reply-To: References: <5374A7F9.6010404@talkunafraid.co.uk> <537673F2.8090701@talkunafraid.co.uk> <20140519065434.GV19870@nerd.dk> Message-ID: Interesting... Doe the site say the persistent store is deprecated/unmaintained? That explains the periodic crashes I get.. ( I'll resuscitate the ticket i had created some months anyway...) Cheers, On 19/05/2014 5:12 pm, "Per Buer" wrote: > Hi, > > On Mon, May 19, 2014 at 8:54 AM, Andreas Plesner Jacobsen wrote: > >> On Fri, May 16, 2014 at 09:24:18PM +0100, James Harrison wrote: >> > > >> > Good to know. There's more than just that one bug, though - just had >> > an hourlong site outage due to varnish's child just up and dying and >> > not being restarted. Wouldn't know where to look for debug output - >> > restarted the parent and it worked again for about 3 minutes and then >> > the child didn't die but it did stop servicing requests. New requests >> > would be accepted, and held open, but nothing happened subsequently. >> > >> > Just downgraded to 3.0 and everything's working again. Persistent >> > storage is a nice-to-have to avoid cold caches after restarts/crashes, >> > but 4.0 clearly needs some work before it goes anywhere near production. >> >> It sounds like you've upgraded to get persistent? Persistent is still >> experimental, just as it was in 3.0. >> > > Experimental is misleading, it makes it sound like the code has a future. > I think the persistence code is still there because nobody has bothered > disabling it yet. > > There is no work being done on the persistent. I doubt someone will pick > it up. > > -- > *Per Buer* > CTO | Varnish Software > Phone: +47 958 39 117 | Skype: per.buer > We Make Websites Fly! > > Winner of the Red Herring Top 100 Global Award 2013 > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Tue May 20 07:05:48 2014 From: perbu at varnish-software.com (Per Buer) Date: Tue, 20 May 2014 09:05:48 +0200 Subject: Future of -spersistent (was: Threads in 4.0) In-Reply-To: <49397.1400534809@critter.freebsd.dk> References: <5374A7F9.6010404@talkunafraid.co.uk> <537673F2.8090701@talkunafraid.co.uk> <20140519065434.GV19870@nerd.dk> <49397.1400534809@critter.freebsd.dk> Message-ID: Hi, On Mon, May 19, 2014 at 11:26 PM, Poul-Henning Kamp wrote: > In message < > CAOXZevAPWdZFezc+saBAJSAv6yUjjKcQoK1dT2itrbRp2A_Z4g at mail.gmail.com> > , Per Buer writes: > > >> > storage is a nice-to-have to avoid cold caches after restarts/crashes, > >> > but 4.0 clearly needs some work before it goes anywhere near > production. > >> > >> It sounds like you've upgraded to get persistent? Persistent is still > >> experimental, just as it was in 3.0. > > > >Experimental is misleading, it makes it sound like the code has a future. > I > >think the persistence code is still there because nobody has bothered > >disabling it yet. > > > >There is no work being done on the persistent. I doubt someone will pick > it > >up. > > There's no formal decision on the future of -spersistent, but if > Varnish-Software has (also) given up on it, maybe we should make > that decision right now and drop -spersistent before 4.0.1 ? > > Any input? > We've managed to make it run stable at some point. LRU is still missing and the code still discards data by the silo and doesn't do any attempts of salvaging usage data from the silos so the code is not well suited for generic usage. I think we should disable or remove it. If someone wants to pick up the pieces we would be able to provide some guidance and patches so the person could pick up where we left of. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugues at betabrand.com Wed May 21 02:34:33 2014 From: hugues at betabrand.com (Hugues Alary) Date: Tue, 20 May 2014 19:34:33 -0700 Subject: Varnish 4 - VCL Compilation failed - Valid VCL Message-ID: Hi there, I believe Mac OS X is not officially supported, but I figured that since it has always worked, I would ask my question. I just switched to varnish 4 from varnish 3.0.5. After a few trial-error I finally got a VCL that varnish 4 likes. However, I now get this error when trying to start varnish: $ sudo varnishd -a 127.0.0.1:80 -T 127.0.0.1 -s malloc,256M -p http_req_hdr_len=32768 -f /usr/local/etc/varnish/magento.vcl Message from C-compiler: ld: can't open output file for writing './vcl.Qw7naIoS.so.ld_FCIJx5', errno=13 for architecture x86_64 clang: error: unable to remove file: Permission denied clang: error: linker command failed with exit code 1 (use -v to see invocation) Running C-compiler failed, exit 1 VCL compilation failed After fiddling for a bit I discovered that doing a chmod 333 on the directory where vcl.Qw7naIoS.so.ld_FCIJx5 is written would allow varnish to start. Here's the output of dtruss which made me think of doing the chmod. $ sudo dtruss "varnishd -a 127.0.0.1:80 -T 127.0.0.1 -s malloc,256M -p http_req_hdr_len=32768 -f /usr/local/etc/varnish/magento.vcl" SYSCALL(args) = return getdtablesize(0xB, 0x7FFF59051AC0, 0x7FFF59051B20) = 256 0 close(0x100) = -1 Err#9 close(0xFF) = -1 Err#9 close(0xFE) = -1 Err#9 close(0xFD) = -1 Err#9 close(0xFC) = -1 Err#9 close(0xFB) = -1 Err#9 close(0xFA) = -1 Err#9 close(0xF9) = -1 Err#9 close(0xF8) = -1 Err#9 close(0xF7) = -1 Err#9 close(0xF6) = -1 Err#9 close(0xF5) = -1 Err#9 close(0xF4) = -1 Err#9 close(0xF3) = -1 Err#9 close(0xF2) = -1 Err#9 close(0xF1) = -1 Err#9 close(0xF0) = -1 Err#9 close(0xEF) = -1 Err#9 close(0xEE) = -1 Err#9 close(0xED) = -1 Err#9 close(0xEC) = -1 Err#9 close(0xEB) = -1 Err#9 close(0xEA) = -1 Err#9 close(0xE9) = -1 Err#9 close(0xE8) = -1 Err#9 close(0xE7) = -1 Err#9 close(0xE6) = -1 Err#9 close(0xE5) = -1 Err#9 close(0xE4) = -1 Err#9 close(0xE3) = -1 Err#9 close(0xE2) = -1 Err#9 close(0xE1) = -1 Err#9 close(0xE0) = -1 Err#9 close(0xDF) = -1 Err#9 close(0xDE) = -1 Err#9 close(0xDD) = -1 Err#9 close(0xDC) = -1 Err#9 close(0xDB) = -1 Err#9 close(0xDA) = -1 Err#9 close(0xD9) = -1 Err#9 close(0xD8) = -1 Err#9 close(0xD7) = -1 Err#9 close(0xD6) = -1 Err#9 close(0xD5) = -1 Err#9 close(0xD4) = -1 Err#9 close(0xD3) = -1 Err#9 close(0xD2) = -1 Err#9 close(0xD1) = -1 Err#9 close(0xD0) = -1 Err#9 close(0xCF) = -1 Err#9 close(0xCE) = -1 Err#9 close(0xCD) = -1 Err#9 close(0xCC) = -1 Err#9 close(0xCB) = -1 Err#9 close(0xCA) = -1 Err#9 close(0xC9) = -1 Err#9 close(0xC8) = -1 Err#9 close(0xC7) = -1 Err#9 close(0xC6) = -1 Err#9 close(0xC5) = -1 Err#9 close(0xC4) = -1 Err#9 close(0xC3) = -1 Err#9 close(0xC2) = -1 Err#9 close(0xC1) = -1 Err#9 close(0xC0) = -1 Err#9 close(0xBF) = -1 Err#9 close(0xBE) = -1 Err#9 close(0xBD) = -1 Err#9 close(0xBC) = -1 Err#9 close(0xBB) = -1 Err#9 close(0xBA) = -1 Err#9 close(0xB9) = -1 Err#9 close(0xB8) = -1 Err#9 close(0xB7) = -1 Err#9 close(0xB6) = -1 Err#9 close(0xB5) = -1 Err#9 close(0xB4) = -1 Err#9 close(0xB3) = -1 Err#9 close(0xB2) = -1 Err#9 close(0xB1) = -1 Err#9 close(0xB0) = -1 Err#9 close(0xAF) = -1 Err#9 close(0xAE) = -1 Err#9 close(0xAD) = -1 Err#9 close(0xAC) = -1 Err#9 close(0xAB) = -1 Err#9 close(0xAA) = -1 Err#9 close(0xA9) = -1 Err#9 close(0xA8) = -1 Err#9 close(0xA7) = -1 Err#9 close(0xA6) = -1 Err#9 close(0xA5) = -1 Err#9 close(0xA4) = -1 Err#9 close(0xA3) = -1 Err#9 close(0xA2) = -1 Err#9 close(0xA1) = -1 Err#9 close(0xA0) = -1 Err#9 close(0x9F) = -1 Err#9 close(0x9E) = -1 Err#9 close(0x9D) = -1 Err#9 close(0x9C) = -1 Err#9 close(0x9B) = -1 Err#9 close(0x9A) = -1 Err#9 close(0x99) = -1 Err#9 close(0x98) = -1 Err#9 close(0x97) = -1 Err#9 close(0x96) = -1 Err#9 close(0x95) = -1 Err#9 close(0x94) = -1 Err#9 close(0x93) = -1 Err#9 close(0x92) = -1 Err#9 close(0x91) = -1 Err#9 close(0x90) = -1 Err#9 close(0x8F) = -1 Err#9 close(0x8E) = -1 Err#9 close(0x8D) = -1 Err#9 close(0x8C) = -1 Err#9 close(0x8B) = -1 Err#9 close(0x8A) = -1 Err#9 close(0x89) = -1 Err#9 close(0x88) = -1 Err#9 close(0x87) = -1 Err#9 close(0x86) = -1 Err#9 close(0x85) = -1 Err#9 close(0x84) = -1 Err#9 close(0x83) = -1 Err#9 close(0x82) = -1 Err#9 close(0x81) = -1 Err#9 close(0x80) = -1 Err#9 close(0x7F) = -1 Err#9 close(0x7E) = -1 Err#9 close(0x7D) = -1 Err#9 close(0x7C) = -1 Err#9 close(0x7B) = -1 Err#9 close(0x7A) = -1 Err#9 close(0x79) = -1 Err#9 close(0x78) = -1 Err#9 close(0x77) = -1 Err#9 close(0x76) = -1 Err#9 close(0x75) = -1 Err#9 close(0x74) = -1 Err#9 close(0x73) = -1 Err#9 close(0x72) = -1 Err#9 close(0x71) = -1 Err#9 close(0x70) = -1 Err#9 close(0x6F) = -1 Err#9 close(0x6E) = -1 Err#9 close(0x6D) = -1 Err#9 close(0x6C) = -1 Err#9 close(0x6B) = -1 Err#9 close(0x6A) = -1 Err#9 close(0x69) = -1 Err#9 close(0x68) = -1 Err#9 close(0x67) = -1 Err#9 close(0x66) = -1 Err#9 close(0x65) = -1 Err#9 close(0x64) = -1 Err#9 close(0x63) = -1 Err#9 close(0x62) = -1 Err#9 close(0x61) = -1 Err#9 close(0x60) = -1 Err#9 close(0x5F) = -1 Err#9 close(0x5E) = -1 Err#9 close(0x5D) = -1 Err#9 close(0x5C) = -1 Err#9 close(0x5B) = -1 Err#9 close(0x5A) = -1 Err#9 close(0x59) = -1 Err#9 close(0x58) = -1 Err#9 close(0x57) = -1 Err#9 close(0x56) = -1 Err#9 close(0x55) = -1 Err#9 close(0x54) = -1 Err#9 close(0x53) = -1 Err#9 close(0x52) = -1 Err#9 close(0x51) = -1 Err#9 close(0x50) = -1 Err#9 close(0x4F) = -1 Err#9 close(0x4E) = -1 Err#9 close(0x4D) = -1 Err#9 close(0x4C) = -1 Err#9 close(0x4B) = -1 Err#9 close(0x4A) = -1 Err#9 close(0x49) = -1 Err#9 close(0x48) = -1 Err#9 close(0x47) = -1 Err#9 close(0x46) = -1 Err#9 close(0x45) = -1 Err#9 close(0x44) = -1 Err#9 close(0x43) = -1 Err#9 close(0x42) = -1 Err#9 close(0x41) = -1 Err#9 close(0x40) = -1 Err#9 close(0x3F) = -1 Err#9 close(0x3E) = -1 Err#9 close(0x3D) = -1 Err#9 close(0x3C) = -1 Err#9 close(0x3B) = -1 Err#9 close(0x3A) = -1 Err#9 close(0x39) = -1 Err#9 close(0x38) = -1 Err#9 close(0x37) = -1 Err#9 close(0x36) = -1 Err#9 close(0x35) = -1 Err#9 close(0x34) = -1 Err#9 close(0x33) = -1 Err#9 close(0x32) = -1 Err#9 close(0x31) = -1 Err#9 close(0x30) = -1 Err#9 close(0x2F) = -1 Err#9 close(0x2E) = -1 Err#9 close(0x2D) = -1 Err#9 close(0x2C) = -1 Err#9 close(0x2B) = -1 Err#9 close(0x2A) = -1 Err#9 close(0x29) = -1 Err#9 close(0x28) = -1 Err#9 close(0x27) = -1 Err#9 close(0x26) = -1 Err#9 close(0x25) = -1 Err#9 close(0x24) = -1 Err#9 close(0x23) = -1 Err#9 close(0x22) = -1 Err#9 close(0x21) = -1 Err#9 close(0x20) = -1 Err#9 close(0x1F) = -1 Err#9 close(0x1E) = -1 Err#9 close(0x1D) = -1 Err#9 close(0x1C) = -1 Err#9 close(0x1B) = -1 Err#9 close(0x1A) = -1 Err#9 close(0x19) = -1 Err#9 close(0x18) = -1 Err#9 close(0x17) = -1 Err#9 close(0x16) = -1 Err#9 close(0x15) = -1 Err#9 close(0x14) = -1 Err#9 close(0x13) = -1 Err#9 close(0x12) = -1 Err#9 close(0x11) = -1 Err#9 close(0x10) = -1 Err#9 close(0xF) = -1 Err#9 close(0xE) = -1 Err#9 close(0xD) = -1 Err#9 close(0xC) = -1 Err#9 close(0xB) = -1 Err#9 close(0xA) = -1 Err#9 close(0x9) = -1 Err#9 close(0x8) = -1 Err#9 close(0x7) = -1 Err#9 close(0x6) = -1 Err#9 close(0x5) = -1 Err#9 close(0x4) = -1 Err#9 close(0x3) = -1 Err#9 open("/dev/urandom\0", 0x0, 0xFFFFFFFFFFFFFFFF) = 3 0 read(0x3, "\a\003\v!\017\376\275\350\0", 0x8) = 8 0 close(0x3) = 0 0 __sysctl(0x7FFF59051438, 0x2, 0x7FFF59051570) = 0 0 __sysctl(0x7FFF59051438, 0x2, 0x7FFF59051670) = 0 0 __sysctl(0x7FFF59051438, 0x2, 0x7FFF59051770) = 0 0 __sysctl(0x7FFF59051438, 0x2, 0x7FFF59051870) = 0 0 __sysctl(0x7FFF59051438, 0x2, 0x7FFF59051970) = 0 0 pipe(0x7FFF59051438, 0x7FFF8CF217CE, 0x7FFF59050E38) = 3 0 fcntl_nocancel(0x3, 0x3, 0x0) = 0 0 getrlimit(0x1008, 0x7FFF59051280, 0x7FFF8CEC8E7C) = 0 0 posix_spawn(0x7FFF59051434, 0x7FFF8CF205A3, 0x7FFF59051370) = 0 0 close_nocancel(0x4) = 0 0 fstat64(0x3, 0x7FFF590512F8, 0x7FFF590513BC) = 0 0 __sysctl(0x7FFF59050BE8, 0x2, 0x7FFF59050BB0) = 0 0 __sysctl(0x7FFF59050BB0, 0x2, 0x7FFF729CF430) = 0 0 socket(0x20, 0x2, 0x2) = 3 0 setsockopt(0x3, 0xFFFF, 0x1022) = 0 0 ioctl(0x3, 0xC0644E03, 0x7FFF59050B20) = 0 0 connect(0x3, 0x7FFF59050B90, 0x20) = 0 0 setsockopt(0x3, 0xFFFF, 0x1002) = 0 0 fcntl(0x3, 0x3, 0x0) = 2 0 fcntl(0x3, 0x4, 0x6) = 0 0 sendto(0x3, 0x7FFF59050CC0, 0x24) = -1 Err#22 open("/Library/Preferences/com.apple.networkd.plist\0", 0x0, 0x2060) = -1 Err#2 socket(0x20, 0x2, 0x2) = 4 0 setsockopt(0x4, 0xFFFF, 0x1022) = 0 0 ioctl(0x4, 0xC0644E03, 0x7FFF590508F0) = 0 0 connect(0x4, 0x7FFF59050960, 0x20) = 0 0 setsockopt(0x4, 0xFFFF, 0x1002) = 0 0 fcntl(0x4, 0x3, 0x0) = 2 0 fcntl(0x4, 0x4, 0x6) = 0 0 sendto(0x4, 0x7FFF59050A50, 0x50) = 80 0 recvfrom(0x4, 0x7FFF59050A50, 0x50) = 24 0 sendto(0x4, 0x7FFF59050AA0, 0x14) = 20 0 recvfrom(0x4, 0x7FFF59050AA0, 0x74) = 116 0 sendto(0x4, 0x7FFF59050B20, 0x14) = 20 0 recvfrom(0x4, 0x7FFF59050B20, 0x8C) = 140 0 close(0x4) = 0 0 sendto(0x3, 0x7FFF59050CC0, 0x24) = -1 Err#22 socket(0x20, 0x2, 0x2) = 4 0 setsockopt(0x4, 0xFFFF, 0x1022) = 0 0 ioctl(0x4, 0xC0644E03, 0x7FFF590508F0) = 0 0 connect(0x4, 0x7FFF59050960, 0x20) = 0 0 setsockopt(0x4, 0xFFFF, 0x1002) = 0 0 fcntl(0x4, 0x3, 0x0) = 2 0 fcntl(0x4, 0x4, 0x6) = 0 0 sendto(0x4, 0x7FFF59050A50, 0x50) = 80 0 recvfrom(0x4, 0x7FFF59050A50, 0x50) = 20 0 close(0x4) = 0 0 open("/usr/local/etc/varnish/magento.vcl\0", 0x0, 0x0) = 4 0 fstat64(0x4, 0x7FFF59050F70, 0x0) = 0 0 read(0x4, "vcl 4;\n\ninclude \"/usr/local/etc/varnish/identify_device.vcl\";\n\nimport std;\nimport directors;\n\nbackend local {\n\t.host = \"127.0.0.1\";\n\t.port = \"8080\";\n\t.connect_timeout = 300s;\n\t.first_byte_timeout = 300s;\n\t.between_bytes_timeout = 300s;\n/*\t.probe = { \n\t\t.re", 0x336B) = 13163 0 close(0x4) = 0 0 __sysctl(0x7FFF59050AF0, 0x2, 0x7FFF59051040) = 0 0 read_nocancel(0x3, "\0", 0x4000) = 0 0 close_nocancel(0x3) = 0 0 wait4_nocancel(0x9B06, 0x7FFF59051454, 0x0) = 39686 0 issetugid(0x7FCFEBE000B3, 0x7FCFED000000, 0x7FFF59051030) = 0 0 open_nocancel("/usr/share/zoneinfo/UTC\0", 0x0, 0x0) = 3 0 fstat64(0x3, 0x7FFF59050F60, 0x0) = 0 0 read_nocancel(0x3, "TZif\0", 0x2A64) = 56 0 close_nocancel(0x3) = 0 0 shm_open(0x7FFF827E0CE4, 0x0, 0x0) = 3 0 mmap(0x0, 0x1000, 0x1, 0x1, 0x3, 0x0) = 0x106C51000 0 close_nocancel(0x3) = 0 0 issetugid(0x7FFF8CF1EAE9, 0x7FCFED003C00, 0x7FFF59050620) = 0 0 fork() = 39688 0 close(0x5) = 0 0 fork() = 39689 0 close(0x5) = 0 0 getuid(0x0, 0x1503, 0x7FFF730EA4E0) = 0 0 getgid(0x0, 0x1503, 0x0) = 0 0 geteuid(0x830000008403, 0x840000008400, 0x106C501F8) = 0 0 mkdir("/usr/local/var/varnish/Hugues-Alarys-MacBook-Pro.local/\0", 0x1ED, 0x7FFF730EA5A8) = -1 Err#17 chdir("/usr/local/var/varnish/Hugues-Alarys-MacBook-Pro.local/\0", 0x1ED, 0xFFFFFFFFFFFFFFFF) = 0 0 open("_.testfile\0", 0xA02, 0x180) = 4 0 close(0x4) = 0 0 unlink("_.testfile\0", 0xA02, 0x0) = 0 0 open("./vcl.UERNcbe6.c\0", 0xA02, 0x180) = 4 0 fchown(0x4, 0xFFFFFFFE, 0xFFFFFFFF) = 0 0 close(0x4) = 0 0 pipe(0x7FFF59050F48, 0x106BF892A, 0x7FFF59050F98) = 4 0 thread_selfid(0x0, 0x1DC0, 0x7FFF65FF8550) = 945954 0 csops(0x0, 0x0, 0x7FFF590511B4) = 0 0 issetugid(0x0, 0x0, 0x0) = 0 0 shared_region_check_np(0x7FFF5904F0E8, 0x106BAE000, 0x4) = 0 0 stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF59050298, 0x7FFF590511D0) = 0 0 open("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x0, 0x0) = 3 0 pread(0x3, "\312\376\272\276\0", 0x1000, 0x0) = 4096 0 pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x1000) = 4096 0 fcntl(0x3, 0x3D, 0x7FFF5904E600) = 0 0 mmap(0x106C36000, 0x2000, 0x5, 0x12, 0x3, 0x1000) = 0x106C36000 0 mmap(0x106C38000, 0x1000, 0x3, 0x12, 0x3, 0x3000) = 0x106C38000 0 mmap(0x106C39000, 0x2050, 0x1, 0x12, 0x3, 0x4000) = 0x106C39000 0 close(0x3) = 0 0 stat64("/usr/local/Cellar/varnish/4.0.0/lib/varnish/libvarnish.dylib\0", 0x7FFF59050048, 0x7FFF59050EE0) = 0 0 open("/usr/local/Cellar/varnish/4.0.0/lib/varnish/libvarnish.dylib\0", 0x0, 0x0) = 3 0 pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x0) = 4096 0 mmap(0x106C3C000, 0xF000, 0x5, 0x12, 0x3, 0x0) = 0x106C3C000 0 mmap(0x106C4B000, 0x1000, 0x3, 0x12, 0x3, 0xF000) = 0x106C4B000 0 mmap(0x106C4C000, 0x2CCC, 0x1, 0x12, 0x3, 0x10000) = 0x106C4C000 0 fcntl(0x3, 0x2C, 0x7FFF5904E388) = 0 0 close(0x3) = 0 0 stat64("/usr/local/Cellar/varnish/4.0.0/lib/varnish/libvarnishcompat.dylib\0", 0x7FFF59050048, 0x7FFF59050EE0) = 0 0 open("/usr/local/Cellar/varnish/4.0.0/lib/varnish/libvarnishcompat.dylib\0", 0x0, 0x0) = 3 0 pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x0) = 4096 0 mmap(0x106C55000, 0x1000, 0x5, 0x12, 0x3, 0x0) = 0x106C55000 0 mmap(0x106C56000, 0x1000, 0x3, 0x12, 0x3, 0x1000) = 0x106C56000 0 mmap(0x106C57000, 0x268, 0x1, 0x12, 0x3, 0x2000) = 0x106C57000 0 fcntl(0x3, 0x2C, 0x7FFF5904E548) = 0 0 close(0x3) = 0 0 stat64("/usr/local/Cellar/varnish/4.0.0/lib/varnish/libvcc.dylib\0", 0x7FFF59050048, 0x7FFF59050EE0) = 0 0 open("/usr/local/Cellar/varnish/4.0.0/lib/varnish/libvcc.dylib\0", 0x0, 0x0) = 3 0 pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x0) = 4096 0 mmap(0x106C5B000, 0x18000, 0x5, 0x12, 0x3, 0x0) = 0x106C5B000 0 mmap(0x106C73000, 0x2000, 0x3, 0x12, 0x3, 0x18000) = 0x106C73000 0 mmap(0x106C75000, 0x20E8, 0x1, 0x12, 0x3, 0x1A000) = 0x106C75000 0 fcntl(0x3, 0x2C, 0x7FFF5904E418) = 0 0 close(0x3) = 0 0 stat64("/usr/local/Cellar/varnish/4.0.0/lib/varnish/libvgz.dylib\0", 0x7FFF59050048, 0x7FFF59050EE0) = 0 0 open("/usr/local/Cellar/varnish/4.0.0/lib/varnish/libvgz.dylib\0", 0x0, 0x0) = 3 0 pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x0) = 4096 0 mmap(0x106C7E000, 0xF000, 0x5, 0x12, 0x3, 0x0) = 0x106C7E000 0 mmap(0x106C8D000, 0x1000, 0x3, 0x12, 0x3, 0xF000) = 0x106C8D000 0 mmap(0x106C8E000, 0x129C, 0x1, 0x12, 0x3, 0x10000) = 0x106C8E000 0 fcntl(0x3, 0x2C, 0x7FFF5904E418) = 0 0 close(0x3) = 0 0 stat64("/usr/local/lib/libpcre.1.dylib\0", 0x7FFF59050048, 0x7FFF59050EE0) = 0 0 open("/usr/local/lib/libpcre.1.dylib\0", 0x0, 0x0) = 3 0 pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x0) = 4096 0 mmap(0x106C93000, 0x63000, 0x5, 0x12, 0x3, 0x0) = 0x106C93000 0 mmap(0x106CF6000, 0x1000, 0x3, 0x12, 0x3, 0x63000) = 0x106CF6000 0 mmap(0x106CF7000, 0x2518, 0x1, 0x12, 0x3, 0x64000) = 0x106CF7000 0 fcntl(0x3, 0x2C, 0x7FFF5904E378) = 0 0 close(0x3) = 0 0 stat64("/usr/lib/libSystem.B.dylib\0", 0x7FFF59050048, 0x7FFF59050EE0) = 0 0 stat64("/usr/lib/system/libcache.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libcommonCrypto.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libcompiler_rt.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libcopyfile.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libcorecrypto.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libdispatch.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libdyld.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libkeymgr.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/liblaunch.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libmacho.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libquarantine.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libremovefile.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_asl.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_blocks.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_c.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_configuration.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_dnssd.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_info.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_kernel.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_m.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_malloc.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_network.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_notify.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_platform.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_pthread.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_sandbox.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libsystem_stats.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libunc.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libunwind.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/system/libxpc.dylib\0", 0x7FFF5904FAB8, 0x7FFF59050950) = 0 0 stat64("/usr/lib/libobjc.A.dylib\0", 0x7FFF5904ECF8, 0x7FFF5904FB90) = 0 0 stat64("/usr/lib/libauto.dylib\0", 0x7FFF5904ECF8, 0x7FFF5904FB90) = 0 0 stat64("/usr/lib/libc++abi.dylib\0", 0x7FFF5904E7A8, 0x7FFF5904F640) = 0 0 stat64("/usr/lib/libc++.1.dylib\0", 0x7FFF5904E7A8, 0x7FFF5904F640) = 0 0 stat64("/usr/lib/libDiagnosticMessagesClient.dylib\0", 0x7FFF5904E688, 0x7FFF5904F520) = 0 0 getpid(0x7FFF59050FA8, 0x106C33004, 0xEA60) = 39685 0 __sysctl(0x7FFF590509C8, 0x2, 0x7FFF590509D8) = 0 0 thread_selfid(0x7FFF71B1C310, 0x7FFF71B1C258, 0x10101) = 945954 0 bsdthread_register(0x7FFF82403FBC, 0x7FFF82403FAC, 0x2000) = 0 0 mprotect(0x106C34000, 0x88, 0x1) = 0 0 mprotect(0x106CFA000, 0x1000, 0x0) = 0 0 mprotect(0x106D10000, 0x1000, 0x0) = 0 0 mprotect(0x106D11000, 0x1000, 0x0) = 0 0 mprotect(0x106D27000, 0x1000, 0x0) = 0 0 mprotect(0x106C4F000, 0x1000, 0x1) = 0 0 mprotect(0x106C34000, 0x88, 0x3) = 0 0 mprotect(0x106C34000, 0x88, 0x1) = 0 0 issetugid(0x7FFF71C44480, 0x7FFFFFE00034, 0x7FFFFFE00036) = 0 0 getpid(0x1, 0x106C50000, 0x49656E69) = 39685 0 __mac_syscall(0x7FFF86BD6E3F, 0x2, 0x7FFF59050848) = 0 0 stat64("/AppleInternal\0", 0x7FFF590508C8, 0x0) = -1 Err#2 audit_session_self(0x7FFF59050780, 0x7FFF590505B8, 0x4) = 4099 0 geteuid(0x7FFF59050780, 0x7FFF590505B8, 0x0) = 0 0 getegid(0x7FFF59050780, 0x7FFF590505B8, 0x0) = 0 0 getaudit_addr(0x7FFF59050858, 0x30, 0x0) = 0 0 csops(0x9B05, 0x7, 0x7FFF59050440) = -1 Err#22 open("/dev/dtracehelper\0", 0x2, 0x7FFF590510A0) = 3 0 ioctl(0x3, 0x80086804, 0x7FFF59051028) = 0 0 close(0x3) = 0 0 open_nocancel("/usr/share/zoneinfo/UTC\0", 0x0, 0x0) = 3 0 fstat64(0x3, 0x7FFF59050530, 0x0) = 0 0 read_nocancel(0x3, "TZif\0", 0x2A64) = 56 0 close_nocancel(0x3) = 0 0 issetugid(0x7FFF85DADA90, 0x7FFF59051314, 0x7FCFEBE00000) = 0 0 issetugid(0x7FFF72387678, 0x0, 0x0) = 0 0 read(0x4, "\0", 0x3FF) = 0 0 close(0x4) = 0 0 wait4(0x9B08, 0x7FFF59050F44, 0x0) = 39688 0 open("./vcl.UERNcbe6.so\0", 0x601, 0x180) = 4 0 fchown(0x4, 0xFFFFFFFE, 0xFFFFFFFF) = 0 0 close(0x4) = 0 0 pipe(0x7FFF59050F48, 0x106BF8BBF, 0x7FCFEBF010D0) = 4 0 Message from C-compiler: ld: can't open output file for writing './vcl.UERNcbe6.so.ld_qBYRde', errno=13 for architecture x86_64 clang: error: unable to remove file: Permission denied clang: error: linker command failed with exit code 1 (use -v to see invocation) Running C-compiler failed, exit 1 VCL compilation failed read(0x4, "ld: can't open output file for writing './vcl.UERNcbe6.so.ld_qBYRde', errno=13 for architecture x86_64\n\0", 0x3FF) = 103 0 read(0x4, "\006\233\0", 0x3FF) = 0 0 close(0x4) = 0 0 wait4(0x9B09, 0x7FFF59050F44, 0x0) = 39689 0 unlink("./vcl.UERNcbe6.c\0", 0x1FF, 0x128) = 0 0 unlink("./vcl.UERNcbe6.so\0", 0xEBF00021, 0xFB540) = 0 0 write_nocancel(0x2, "Message from C-compiler:\nld: can't open output file for writing './vcl.UERNcbe6.so.ld_qBYRde', errno=13 for architecture x86_64\nclang: error: unable to remove file: Permission denied\nclang: error: linker command failed with exit code 1 (use -v to see invoc", 0x129) = 297 0 write_nocancel(0x2, "\nVCL compilation failed\n\0", 0x18) = 24 0 read(0x4, "clang: error\0", 0x3FF) = 12 0 read(0x4, ": unable to remove file: Permission denied\nclang: error: linker command failed with exit code 1 (use -v to see invocation)\n\0", 0x3F3) = 123 0 Any chance anybody knows what's happening? Thanks, -Hugues -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugues at betabrand.com Wed May 21 04:57:49 2014 From: hugues at betabrand.com (Hugues Alary) Date: Tue, 20 May 2014 21:57:49 -0700 Subject: Varnish 4 - VCL Compilation failed - Valid VCL In-Reply-To: References: Message-ID: After looking into this more, it seems to be just a small permission problem. Doing a chmod 777 on the directory containing the compiled VCL does the trick. My guess is that when varnishd is runs, it switches from root to nobody, and nobody doesn't have the right permissions for that directory. Not sure what changed between 3.0.5 and 4.0. Maybe the VCL compilation is not carried by root anymore but by nobody? For security reasons? -H -------------- next part -------------- An HTML attachment was scrubbed... URL: From apj at mutt.dk Wed May 21 07:14:19 2014 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Wed, 21 May 2014 09:14:19 +0200 Subject: Threads in 4.0 In-Reply-To: References: <5374A7F9.6010404@talkunafraid.co.uk> <537673F2.8090701@talkunafraid.co.uk> <20140519065434.GV19870@nerd.dk> Message-ID: <20140521071419.GX19870@nerd.dk> On Tue, May 20, 2014 at 08:39:33AM +1000, Norberto Meijome wrote: > Interesting... Doe the site say the persistent store is > deprecated/unmaintained? man varnishd has the following to say: persistent (experimental) syntax: persistent,path,size Persistent storage. Varnish will store objects in a file in a manner that will secure the survival of most of the objects in the event of a planned or unplanned shutdown of Varnish. The persistent storage back? end has multiple issues with it and will likely be removed from a future version of Varnish. -- Andreas From jprr773 at gmail.com Wed May 21 18:11:17 2014 From: jprr773 at gmail.com (Joao Rios) Date: Wed, 21 May 2014 19:11:17 +0100 Subject: Help on Varnish configuration problem on Centos 6.5 Message-ID: Hi , I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. After installing the rpm and follow the installation procedures, it seems the service fails to start: # service varnish restart Stopping Varnish Cache: [FAILED] Starting Varnish Cache: [ OK ] I really appreciate in advance all the help you can give. Here are the details: installed Varnish For RHEL 6: # rpm --nosignature -i http://repo.varnish-cache.org/redhat/varnish-3.0/el6/noarch/varnish-release/varnish-release-3.0-1.el6.noarch.rpm and then: # yum install varnish Centos Version: #cat /etc/redhat-release CentOS release 6.5 (Final) Apache version: # httpd -v Server version: Apache/2.2.27 (Unix) Server built: May 17 2014 12:17:16 Cpanel::Easy::Apache v3.24.18 rev9999 Varnish version: # varnishd -V varnishd (varnish-3.0.5 revision 1a89b1f) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS # service varnish restart Stopping Varnish Cache: [FAILED] Starting Varnish Cache: [ OK ] Configuration: # /etc/sysconfig/varnish # Configuration file for varnish # # /etc/init.d/varnish expects the variable $DAEMON_OPTS to be set from this # shell script fragment. # # Maximum number of open files (for ulimit -n) NFILES=131072 # Locked shared memory (for ulimit -l) # Default log size is 82MB + header MEMLOCK=82000 # Maximum number of threads (for ulimit -u) NPROCS="unlimited" # Maximum size of corefile (for ulimit -c). Default in Fedora is 0 # DAEMON_COREFILE_LIMIT="unlimited" # Set this to 1 to make init script reload try to switch vcl without restart. # To make this work, you need to set the following variables # explicit: VARNISH_VCL_CONF, VARNISH_ADMIN_LISTEN_ADDRESS, # VARNISH_ADMIN_LISTEN_PORT, VARNISH_SECRET_FILE, or in short, # use Alternative 3, Advanced configuration, below RELOAD_VCL=1 # This file contains 4 alternatives, please use only one. ## Alternative 1, Minimal configuration, no VCL # # Listen on port 6081, administration on localhost:6082, and forward to # content server on localhost:8080. Use a fixed-size cache file. # #DAEMON_OPTS="-a :6081 \ # -T localhost:6082 \ # -b localhost:8080 \ # -u varnish -g varnish \ # -s file,/var/lib/varnish/varnish_storage.bin,1G" ## Alternative 2, Configuration with VCL # # Listen on port 6081, administration on localhost:6082, and forward to # one content server selected by the vcl file, based on the request. Use a # fixed-size cache file. # ###DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -u varnish -g varnish -S /etc/varnish/secret -s file,/var/lib/varnish/varnish_storage.bin,256m" ## Alternative 3, Advanced configuration # # See varnishd(1) for more information. # # # Main configuration file. You probably want to change it :) VARNISH_VCL_CONF=/etc/varnish/default.vcl # # # Default address and port to bind to # # Blank address means all IPv4 and IPv6 interfaces, otherwise specify # # a host name, an IPv4 dotted quad, or an IPv6 address in brackets. VARNISH_LISTEN_ADDRESS=37.61.236.139 VARNISH_LISTEN_PORT=80 # # # Telnet admin interface listen address and port VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1 VARNISH_ADMIN_LISTEN_PORT=6082 # # # Shared secret file for admin interface VARNISH_SECRET_FILE=/etc/varnish/secret # # # The minimum number of worker threads to start VARNISH_MIN_THREADS=50 # # # The Maximum number of worker threads to start VARNISH_MAX_THREADS=1000 # # # Idle timeout for worker threads VARNISH_THREAD_TIMEOUT=120 # # # Cache file location VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin # # # Cache file size: in bytes, optionally using k / M / G / T suffix, # # or in percentage of available disk space using the % suffix. VARNISH_STORAGE_SIZE=256m # # # Backend storage specification VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}" # # # Default TTL used when the backend does not specify one VARNISH_TTL=120 # # # DAEMON_OPTS is used by the init script. If you add or remove options, make # # sure you update this section, too. DAEMON_OPTS="-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} -f ${VARNISH_VCL_CONF} -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} -t ${VARNISH_TTL} -w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} -u varnish -g varnish -S ${VARNISH_SECRET_FILE} -s ${VARNISH_STORAGE}" ## Alternative 4, Do It Yourself. See varnishd(1) for more information. # # DAEMON_OPTS="" /etc/varnich/default.vcl # This is a basic VCL configuration file for varnish. See the vcl(7) # man page for details on VCL syntax and semantics. # # Default backend definition. Set this to point to your content # server. # backend default { .host = "127.0.0.1"; .port = "80"; } # # Below is a commented-out copy of the default VCL logic. If you # redefine any of these subroutines, the built-in logic will be # appended to your code. # sub vcl_recv { # if (req.restarts == 0) { # if (req.http.x-forwarded-for) { # set req.http.X-Forwarded-For = # req.http.X-Forwarded-For + ", " + client.ip; # } else { # set req.http.X-Forwarded-For = client.ip; # } # } # if (req.request != "GET" && # req.request != "HEAD" && # req.request != "PUT" && # req.request != "POST" && # req.request != "TRACE" && # req.request != "OPTIONS" && # req.request != "DELETE") { # /* Non-RFC2616 or CONNECT which is weird. */ # return (pipe); # } # if (req.request != "GET" && req.request != "HEAD") { # /* We only deal with GET and HEAD by default */ # return (pass); # } # if (req.http.Authorization || req.http.Cookie) { # /* Not cacheable by default */ # return (pass); # } # return (lookup); # } # sub vcl_pipe { # # Note that only the first request to the backend will have # # X-Forwarded-For set. If you use X-Forwarded-For and want to # # have it set for all requests, make sure to have: # # set bereq.http.connection = "close"; # # here. It is not set by default as it might break some broken web # # applications, like IIS with NTLM authentication. # return (pipe); # } # # sub vcl_pass { # return (pass); # } # # sub vcl_hash { # hash_data(req.url); # if (req.http.host) { # hash_data(req.http.host); # } else { # hash_data(server.ip); # } # return (hash); # } # # sub vcl_hit { # return (deliver); # } # # sub vcl_miss { # return (fetch); # } # # sub vcl_fetch { # if (beresp.ttl <= 0s || # beresp.http.Set-Cookie || # beresp.http.Vary == "*") { # /* # * Mark as "Hit-For-Pass" for the next 2 minutes # */ # set beresp.ttl = 120 s; # return (hit_for_pass); # } # return (deliver); # } # # sub vcl_deliver { # return (deliver); # } # sub vcl_error { # set obj.http.Content-Type = "text/html; charset=utf-8"; # set obj.http.Retry-After = "5"; # synthetic {" # # # # # "} + obj.status + " " + obj.response + {" # # #

Error "} + obj.status + " " + obj.response + {"

#

"} + obj.response + {"

#

Guru Meditation:

#

XID: "} + req.xid + {"

#
#

Varnish cache server

# # # "}; # return (deliver); # } # # sub vcl_init { # return (ok); # } # # sub vcl_fini { # return (ok); # } -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabio at dataspace.com.br Wed May 21 18:30:04 2014 From: fabio at dataspace.com.br (Fabio Fraga [DS]) Date: Wed, 21 May 2014 15:30:04 -0300 Subject: Help on Varnish configuration problem on Centos 6.5 In-Reply-To: References: Message-ID: Hi, Joao. Can you post the output of following command: #varnishd -C -f /etc/varnish/default.vcl I hope it helps. Atenciosamente, F?bio Fraga Machado Diretor de Tecnologia e Infraestrutura Data Space Networks & TI : Telefone: (48) 4052-9252 : MSN: fabio at dataspace.com.br : GTalk: fabio at dataspace.com.br On Wed, May 21, 2014 at 3:11 PM, Joao Rios wrote: > Hi , > > I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. > After installing the rpm and follow the installation procedures, > it seems the service fails to start: > > # service varnish restart > Stopping Varnish Cache: [FAILED] > Starting Varnish Cache: [ OK ] > > I really appreciate in advance all the help you can give. > > > Here are the details: > > > installed Varnish For RHEL 6: > # rpm --nosignature -i > http://repo.varnish-cache.org/redhat/varnish-3.0/el6/noarch/varnish-release/varnish-release-3.0-1.el6.noarch.rpm > > and then: > > > # yum install varnish > > > Centos Version: > > #cat /etc/redhat-release > CentOS release 6.5 (Final) > > Apache version: > # httpd -v > Server version: Apache/2.2.27 (Unix) > Server built: May 17 2014 12:17:16 > Cpanel::Easy::Apache v3.24.18 rev9999 > > > > Varnish version: > # varnishd -V > varnishd (varnish-3.0.5 revision 1a89b1f) > Copyright (c) 2006 Verdens Gang AS > Copyright (c) 2006-2011 Varnish Software AS > > > # service varnish restart > Stopping Varnish Cache: [FAILED] > Starting Varnish Cache: [ OK ] > > > Configuration: > > # /etc/sysconfig/varnish > > > # Configuration file for varnish > # > # /etc/init.d/varnish expects the variable $DAEMON_OPTS to be set from this > # shell script fragment. > # > > # Maximum number of open files (for ulimit -n) > NFILES=131072 > > # Locked shared memory (for ulimit -l) > # Default log size is 82MB + header > MEMLOCK=82000 > > # Maximum number of threads (for ulimit -u) > NPROCS="unlimited" > > # Maximum size of corefile (for ulimit -c). Default in Fedora is 0 > # DAEMON_COREFILE_LIMIT="unlimited" > > # Set this to 1 to make init script reload try to switch vcl without > restart. > # To make this work, you need to set the following variables > # explicit: VARNISH_VCL_CONF, VARNISH_ADMIN_LISTEN_ADDRESS, > # VARNISH_ADMIN_LISTEN_PORT, VARNISH_SECRET_FILE, or in short, > # use Alternative 3, Advanced configuration, below > RELOAD_VCL=1 > > # This file contains 4 alternatives, please use only one. > > ## Alternative 1, Minimal configuration, no VCL > # > # Listen on port 6081, administration on localhost:6082, and forward to > # content server on localhost:8080. Use a fixed-size cache file. > # > #DAEMON_OPTS="-a :6081 \ > # -T localhost:6082 \ > # -b localhost:8080 \ > # -u varnish -g varnish \ > # -s file,/var/lib/varnish/varnish_storage.bin,1G" > > > > ## Alternative 2, Configuration with VCL > # > # Listen on port 6081, administration on localhost:6082, and forward to > # one content server selected by the vcl file, based on the request. Use a > # fixed-size cache file. > # > ###DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -u > varnish -g varnish -S /etc/varnish/secret -s > file,/var/lib/varnish/varnish_storage.bin,256m" > > ## Alternative 3, Advanced configuration > # > # See varnishd(1) for more information. > # > # # Main configuration file. You probably want to change it :) > VARNISH_VCL_CONF=/etc/varnish/default.vcl > # > # # Default address and port to bind to > # # Blank address means all IPv4 and IPv6 interfaces, otherwise specify > # # a host name, an IPv4 dotted quad, or an IPv6 address in brackets. > VARNISH_LISTEN_ADDRESS=37.61.236.139 > VARNISH_LISTEN_PORT=80 > # > # # Telnet admin interface listen address and port > VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1 > VARNISH_ADMIN_LISTEN_PORT=6082 > # > # # Shared secret file for admin interface > VARNISH_SECRET_FILE=/etc/varnish/secret > # > # # The minimum number of worker threads to start > VARNISH_MIN_THREADS=50 > # > # # The Maximum number of worker threads to start > VARNISH_MAX_THREADS=1000 > # > # # Idle timeout for worker threads > VARNISH_THREAD_TIMEOUT=120 > # > # # Cache file location > VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin > # > # # Cache file size: in bytes, optionally using k / M / G / T suffix, > # # or in percentage of available disk space using the % suffix. > VARNISH_STORAGE_SIZE=256m > # > # # Backend storage specification > VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}" > # > # # Default TTL used when the backend does not specify one > VARNISH_TTL=120 > # > # # DAEMON_OPTS is used by the init script. If you add or remove options, > make > # # sure you update this section, too. > DAEMON_OPTS="-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} > -f ${VARNISH_VCL_CONF} > -T > ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} > -t ${VARNISH_TTL} > -w > ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} > -u varnish > -g varnish -S ${VARNISH_SECRET_FILE} -s ${VARNISH_STORAGE}" > > > > ## Alternative 4, Do It Yourself. See varnishd(1) for more information. > # > # DAEMON_OPTS="" > > > > > /etc/varnich/default.vcl > > # This is a basic VCL configuration file for varnish. See the vcl(7) > # man page for details on VCL syntax and semantics. > # > # Default backend definition. Set this to point to your content > # server. > # > backend default { > .host = "127.0.0.1"; > .port = "80"; > } > # > # Below is a commented-out copy of the default VCL logic. If you > # redefine any of these subroutines, the built-in logic will be > # appended to your code. > # sub vcl_recv { > # if (req.restarts == 0) { > # if (req.http.x-forwarded-for) { > # set req.http.X-Forwarded-For = > # req.http.X-Forwarded-For + ", " + client.ip; > # } else { > # set req.http.X-Forwarded-For = client.ip; > # } > # } > # if (req.request != "GET" && > # req.request != "HEAD" && > # req.request != "PUT" && > # req.request != "POST" && > # req.request != "TRACE" && > # req.request != "OPTIONS" && > # req.request != "DELETE") { > # /* Non-RFC2616 or CONNECT which is weird. */ > # return (pipe); > # } > # if (req.request != "GET" && req.request != "HEAD") { > # /* We only deal with GET and HEAD by default */ > # return (pass); > # } > # if (req.http.Authorization || req.http.Cookie) { > # /* Not cacheable by default */ > # return (pass); > # } > # return (lookup); > # } > > # sub vcl_pipe { > # # Note that only the first request to the backend will have > # # X-Forwarded-For set. If you use X-Forwarded-For and want to > # # have it set for all requests, make sure to have: > # # set bereq.http.connection = "close"; > # # here. It is not set by default as it might break some broken web > # # applications, like IIS with NTLM authentication. > # return (pipe); > # } > # > # sub vcl_pass { > # return (pass); > # } > # > # sub vcl_hash { > # hash_data(req.url); > # if (req.http.host) { > # hash_data(req.http.host); > # } else { > # hash_data(server.ip); > # } > # return (hash); > # } > # > > # sub vcl_hit { > # return (deliver); > # } > # > # sub vcl_miss { > # return (fetch); > # } > # > # sub vcl_fetch { > # if (beresp.ttl <= 0s || > # beresp.http.Set-Cookie || > # beresp.http.Vary == "*") { > # /* > # * Mark as "Hit-For-Pass" for the next 2 minutes > # */ > # set beresp.ttl = 120 s; > # return (hit_for_pass); > # } > # return (deliver); > # } > # > # sub vcl_deliver { > # return (deliver); > # } > > # sub vcl_error { > # set obj.http.Content-Type = "text/html; charset=utf-8"; > # set obj.http.Retry-After = "5"; > # synthetic {" > # > # # "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > # > # > # "} + obj.status + " " + obj.response + {" > # > # > #

Error "} + obj.status + " " + obj.response + {"

> #

"} + obj.response + {"

> #

Guru Meditation:

> #

XID: "} + req.xid + {"

> #
> #

Varnish cache server

> # > # > # "}; > # return (deliver); > # } > # > # sub vcl_init { > # return (ok); > # } > # > # sub vcl_fini { > # return (ok); > # } > > > > > > > > > > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at ifixit.com Wed May 21 18:31:47 2014 From: james at ifixit.com (James Pearson) Date: Wed, 21 May 2014 11:31:47 -0700 Subject: Help on Varnish configuration problem on Centos 6.5 In-Reply-To: References: Message-ID: <1400697022-sup-4433@geror.local> Excerpts from Joao Rios's message of 2014-05-21 11:11:17 -0700: > I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. > After installing the rpm and follow the installation procedures, > it seems the service fails to start: > > # service varnish restart > Stopping Varnish Cache: [FAILED] > Starting Varnish Cache: [ OK ] No, that indicates that it didn't stop Varnish (probably because it wasn't running), but it *started* it successfully. Have you verified that it is indeed not running (via ps, lsof, etc.)? - P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From james at ifixit.com Wed May 21 18:37:54 2014 From: james at ifixit.com (James Pearson) Date: Wed, 21 May 2014 11:37:54 -0700 Subject: Varnish 4 - VCL Compilation failed - Valid VCL In-Reply-To: References: Message-ID: <1400697383-sup-6303@geror.local> Excerpts from Hugues Alary's message of 2014-05-20 21:57:49 -0700: > My guess is that when varnishd is runs, it switches from root to nobody, > and nobody doesn't have the right permissions for that directory. I don't know about compilation, but in Varnish 3 the -u and -g options control the user and group to which Varnish will drop. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nemolee888 at gmail.com Thu May 22 01:36:49 2014 From: nemolee888 at gmail.com (=?GB2312?B?wO7Rp8e/?=) Date: Thu, 22 May 2014 09:36:49 +0800 Subject: about hitrate Message-ID: <537D54B1.4090606@gmail.com> Hello everyone: I am a newbie of varnish 4.0 . Can I check the hitrate in the varnishstat command? This command's output is diffrent from version 3.0. Thank you! -- *???? ? ???* ? ????????????512? Tel:(+86-411)84799089 Mobile: 18041169612 Email: lixueqiang at chinafesco.com http://www.chinafesco.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Thu May 22 08:46:28 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Thu, 22 May 2014 09:46:28 +0100 Subject: about hitrate In-Reply-To: <537D54B1.4090606@gmail.com> References: <537D54B1.4090606@gmail.com> Message-ID: Hi, I think you should be able to use varnishtop and varnishlog to achieve what you?re after. varnishtop will let you see which URLs are hitting your backend(s) most often. Something like varnishtop -i txurl might be a good starting point, although the docs[1] have some further details on its use. varnishlog will let you search your logs for a given URL to look at the request. varnishlog -c -m ?RxURL:^/foo/bar? will show you requests from client (-c) for /foo/bar Andrew [1]?https://www.varnish-cache.org/docs/4.0/users-guide/operation-statistics.html#users-guide-statistics On 22 May 2014 at 02:39:38, ??? (nemolee888 at gmail.com) wrote: Hello everyone: ??? I am a newbie of varnish 4.0 . Can I check the hitrate in the varnishstat command? This command's output is diffrent from version 3.0. ??? Thank you! -- ? ???? ? ????? ? ????????????512? Tel:(+86-411)84799089 Mobile: 18041169612 Email: lixueqiang at chinafesco.com http://www.chinafesco.com/ ? _______________________________________________ varnish-misc mailing list varnish-misc at varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jprr773 at gmail.com Thu May 22 09:50:02 2014 From: jprr773 at gmail.com (Joao Rios) Date: Thu, 22 May 2014 10:50:02 +0100 Subject: Help on Varnish configuration problem on Centos 6.5 Message-ID: Hello F?bio, Thank you very much for the reply. I'm newbie with Varnish and I'm looking at the output using # varnishd -C -f /etc/varnish/default.vcl but can't really say what's wrong with it... Can I copy the output here? Obrigado :) Joao On Thu, May 22, 2014 at 2:37 AM, wrote: > Send varnish-misc mailing list submissions to > varnish-misc at varnish-cache.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > or, via email, send a message with subject or body 'help' to > varnish-misc-request at varnish-cache.org > > You can reach the person managing the list at > varnish-misc-owner at varnish-cache.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of varnish-misc digest..." > > > Today's Topics: > > 1. Re: Help on Varnish configuration problem on Centos 6.5 > (James Pearson) > 2. Re: Varnish 4 - VCL Compilation failed - Valid VCL (James Pearson) > 3. about hitrate (???) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 May 2014 11:31:47 -0700 > From: James Pearson > To: varnish-misc > Subject: Re: Help on Varnish configuration problem on Centos 6.5 > Message-ID: <1400697022-sup-4433 at geror.local> > Content-Type: text/plain; charset="utf-8" > > Excerpts from Joao Rios's message of 2014-05-21 11:11:17 -0700: > > I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. > > After installing the rpm and follow the installation procedures, > > it seems the service fails to start: > > > > # service varnish restart > > Stopping Varnish Cache: [FAILED] > > Starting Varnish Cache: [ OK ] > > No, that indicates that it didn't stop Varnish (probably because it wasn't > running), but it *started* it successfully. > > Have you verified that it is indeed not running (via ps, lsof, etc.)? > - P > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 819 bytes > Desc: not available > URL: < > https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140521/f98185a4/attachment-0001.pgp > > > > ------------------------------ > > Message: 2 > Date: Wed, 21 May 2014 11:37:54 -0700 > From: James Pearson > To: varnish-misc > Subject: Re: Varnish 4 - VCL Compilation failed - Valid VCL > Message-ID: <1400697383-sup-6303 at geror.local> > Content-Type: text/plain; charset="utf-8" > > Excerpts from Hugues Alary's message of 2014-05-20 21:57:49 -0700: > > My guess is that when varnishd is runs, it switches from root to nobody, > > and nobody doesn't have the right permissions for that directory. > > I don't know about compilation, but in Varnish 3 the -u and -g options > control > the user and group to which Varnish will drop. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 819 bytes > Desc: not available > URL: < > https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140521/5a9e259a/attachment-0001.pgp > > > > ------------------------------ > > Message: 3 > Date: Thu, 22 May 2014 09:36:49 +0800 > From: ??? > To: varnish-misc at varnish-cache.org > Subject: about hitrate > Message-ID: <537D54B1.4090606 at gmail.com> > Content-Type: text/plain; charset="gb2312" > > Hello everyone: > I am a newbie of varnish 4.0 . Can I check the hitrate in the > varnishstat command? This command's output is diffrent from version 3.0. > Thank you! > > -- > > *???? ? ???* > > ? ????????????512? > > Tel:(+86-411)84799089 > > Mobile: 18041169612 > > Email: lixueqiang at chinafesco.com > > http://www.chinafesco.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140522/2f5370a9/attachment.html > > > > ------------------------------ > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > End of varnish-misc Digest, Vol 98, Issue 33 > ******************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jprr773 at gmail.com Thu May 22 11:10:28 2014 From: jprr773 at gmail.com (Joao Rios) Date: Thu, 22 May 2014 12:10:28 +0100 Subject: Help on Varnish configuration problem on Centos 6.5 Message-ID: Hi James, Thank you so much for the reply. I don't think Varnish is running on port 80. When I execute this: netstat -tulpn , I get: Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 30222/mysqld tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 18407/exim tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 18340/dovecot tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 18599/spamd.pid --m tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 18340/dovecot tcp 0 0 0.0.0.0:2095 0.0.0.0:* LISTEN 1463/cpsrvd (SSL) - tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7866/httpd tcp 0 0 0.0.0.0:2096 0.0.0.0:* LISTEN 1463/cpsrvd (SSL) - tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 18407/exim tcp 0 0 37.61.236.139:49619 0.0.0.0:* LISTEN 13118/pure-ftpd (ID tcp 0 0 37.61.235.212:53 0.0.0.0:* LISTEN 13054/named tcp 0 0 37.61.236.139:53 0.0.0.0:* LISTEN 13054/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 13054/named tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 13118/pure-ftpd (ID tcp 0 0 0.0.0.0:47926 0.0.0.0:* LISTEN 4224/sshd tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 13054/named tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 18407/exim tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 7866/httpd tcp 0 0 0.0.0.0:2077 0.0.0.0:* LISTEN 25872/cpdavd - acce tcp 0 0 0.0.0.0:2078 0.0.0.0:* LISTEN 25872/cpdavd - acce tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 18340/dovecot tcp 0 0 0.0.0.0:2082 0.0.0.0:* LISTEN 1463/cpsrvd (SSL) - tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 18340/dovecot tcp 0 0 0.0.0.0:2083 0.0.0.0:* LISTEN 1463/cpsrvd (SSL) - tcp 0 0 0.0.0.0:2086 0.0.0.0:* LISTEN 1463/cpsrvd (SSL) - tcp 0 0 127.0.0.1:199 0.0.0.0:* LISTEN 4360/snmpd tcp 0 0 0.0.0.0:2087 0.0.0.0:* LISTEN 1463/cpsrvd (SSL) - tcp 0 0 :::587 :::* LISTEN 18407/exim tcp 0 0 :::80 :::* LISTEN 7866/httpd tcp 0 0 :::465 :::* LISTEN 18407/exim tcp 0 0 :::21 :::* LISTEN 13118/pure-ftpd (ID tcp 0 0 :::47926 :::* LISTEN 4224/sshd tcp 0 0 :::25 :::* LISTEN 18407/exim tcp 0 0 :::443 :::* LISTEN 7866/httpd udp 0 0 0.0.0.0:161 0.0.0.0:* 4360/snmpd udp 0 0 37.61.235.212:53 0.0.0.0:* 13054/named udp 0 0 37.61.236.139:53 0.0.0.0:* 13054/named udp 0 0 127.0.0.1:53 0.0.0.0:* 13054/named udp 0 0 37.61.235.212:123 0.0.0.0:* 1130/ntpd udp 0 0 37.61.236.139:123 0.0.0.0:* 1130/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 1130/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 1130/ntpd udp 0 0 fe80::216:3eff:fead:d8c:123 :::* 1130/ntpd udp 0 0 ::1:123 :::* 1130/ntpd udp 0 0 :::123 :::* 1130/ntpd > Excerpts from Joao Rios's message of 2014-05-21 11:11:17 -0700: > > I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. > > After installing the rpm and follow the installation procedures, > > it seems the service fails to start: > > > > # service varnish restart > > Stopping Varnish Cache: [FAILED] > > Starting Varnish Cache: [ OK ] > > No, that indicates that it didn't stop Varnish (probably because it wasn't > running), but it *started* it successfully. > > Have you verified that it is indeed not running (via ps, lsof, etc.)? > - P > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jprr773 at gmail.com Thu May 22 11:19:36 2014 From: jprr773 at gmail.com (Joao Rios) Date: Thu, 22 May 2014 12:19:36 +0100 Subject: Help on Varnish configuration problem on Centos 6.5 Message-ID: Well, if I : # ps -ef | grep varnishd , I get this: root 13560 13314 0 14:18 pts/3 00:00:00 grep varnishd On Thu, May 22, 2014 at 12:10 PM, Joao Rios wrote: > Hi James, > Thank you so much for the reply. > I don't think Varnish is running on port 80. > > When I execute this: netstat -tulpn , I get: > > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign > Address State PID/Program name > tcp 0 0 0.0.0.0:3306 0.0.0.0:* > LISTEN 30222/mysqld > tcp 0 0 0.0.0.0:587 0.0.0.0:* > LISTEN 18407/exim > tcp 0 0 0.0.0.0:110 0.0.0.0:* > LISTEN 18340/dovecot > tcp 0 0 127.0.0.1:783 0.0.0.0:* > LISTEN 18599/spamd.pid --m > tcp 0 0 0.0.0.0:143 0.0.0.0:* > LISTEN 18340/dovecot > tcp 0 0 0.0.0.0:2095 0.0.0.0:* > LISTEN 1463/cpsrvd (SSL) - > tcp 0 0 0.0.0.0:80 0.0.0.0:* > LISTEN 7866/httpd > tcp 0 0 0.0.0.0:2096 0.0.0.0:* > LISTEN 1463/cpsrvd (SSL) - > tcp 0 0 0.0.0.0:465 0.0.0.0:* > LISTEN 18407/exim > tcp 0 0 37.61.236.139:49619 0.0.0.0:* > LISTEN 13118/pure-ftpd (ID > tcp 0 0 37.61.235.212:53 0.0.0.0:* > LISTEN 13054/named > tcp 0 0 37.61.236.139:53 0.0.0.0:* > LISTEN 13054/named > tcp 0 0 127.0.0.1:53 0.0.0.0:* > LISTEN 13054/named > tcp 0 0 0.0.0.0:21 0.0.0.0:* > LISTEN 13118/pure-ftpd (ID > tcp 0 0 0.0.0.0:47926 0.0.0.0:* > LISTEN 4224/sshd > tcp 0 0 127.0.0.1:953 0.0.0.0:* > LISTEN 13054/named > tcp 0 0 0.0.0.0:25 0.0.0.0:* > LISTEN 18407/exim > tcp 0 0 0.0.0.0:443 0.0.0.0:* > LISTEN 7866/httpd > tcp 0 0 0.0.0.0:2077 0.0.0.0:* > LISTEN 25872/cpdavd - acce > tcp 0 0 0.0.0.0:2078 0.0.0.0:* > LISTEN 25872/cpdavd - acce > tcp 0 0 0.0.0.0:993 0.0.0.0:* > LISTEN 18340/dovecot > tcp 0 0 0.0.0.0:2082 0.0.0.0:* > LISTEN 1463/cpsrvd (SSL) - > tcp 0 0 0.0.0.0:995 0.0.0.0:* > LISTEN 18340/dovecot > tcp 0 0 0.0.0.0:2083 0.0.0.0:* > LISTEN 1463/cpsrvd (SSL) - > tcp 0 0 0.0.0.0:2086 0.0.0.0:* > LISTEN 1463/cpsrvd (SSL) - > tcp 0 0 127.0.0.1:199 0.0.0.0:* > LISTEN 4360/snmpd > tcp 0 0 0.0.0.0:2087 0.0.0.0:* > LISTEN 1463/cpsrvd (SSL) - > tcp 0 0 :::587 > :::* LISTEN 18407/exim > tcp 0 0 :::80 > :::* LISTEN 7866/httpd > tcp 0 0 :::465 > :::* LISTEN 18407/exim > tcp 0 0 :::21 > :::* LISTEN 13118/pure-ftpd (ID > tcp 0 0 :::47926 > :::* LISTEN 4224/sshd > tcp 0 0 :::25 > :::* LISTEN 18407/exim > tcp 0 0 :::443 > :::* LISTEN 7866/httpd > udp 0 0 0.0.0.0:161 0.0.0.0:* > 4360/snmpd > udp 0 0 37.61.235.212:53 0.0.0.0:* > 13054/named > udp 0 0 37.61.236.139:53 0.0.0.0:* > 13054/named > udp 0 0 127.0.0.1:53 0.0.0.0:* > 13054/named > udp 0 0 37.61.235.212:123 0.0.0.0:* > 1130/ntpd > udp 0 0 37.61.236.139:123 0.0.0.0:* > 1130/ntpd > udp 0 0 127.0.0.1:123 0.0.0.0:* > 1130/ntpd > udp 0 0 0.0.0.0:123 0.0.0.0:* > 1130/ntpd > udp 0 0 fe80::216:3eff:fead:d8c:123 > :::* 1130/ntpd > udp 0 0 ::1:123 > :::* 1130/ntpd > udp 0 0 :::123 > :::* 1130/ntpd > > > >> Excerpts from Joao Rios's message of 2014-05-21 11:11:17 -0700: >> > I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. >> > After installing the rpm and follow the installation procedures, >> > it seems the service fails to start: >> > >> > # service varnish restart >> > Stopping Varnish Cache: [FAILED] >> > Starting Varnish Cache: [ OK ] >> >> No, that indicates that it didn't stop Varnish (probably because it wasn't >> running), but it *started* it successfully. >> >> Have you verified that it is indeed not running (via ps, lsof, etc.)? >> - P >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Thu May 22 11:46:16 2014 From: perbu at varnish-software.com (Per Buer) Date: Thu, 22 May 2014 13:46:16 +0200 Subject: Help on Varnish configuration problem on Centos 6.5 In-Reply-To: References: Message-ID: Varnish is not running. When it doesn't start you can check syslog. It will probably say something like "can't bind to port". The reason is obvious (for me at least :-). tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7866/httpd You have apache running on port 80 so Varnish can't bind to the port. On Thu, May 22, 2014 at 1:19 PM, Joao Rios wrote: > Well, if I : # ps -ef | grep varnishd , > > I get this: > > root 13560 13314 0 14:18 pts/3 00:00:00 grep varnishd > > > > On Thu, May 22, 2014 at 12:10 PM, Joao Rios wrote: > >> Hi James, >> Thank you so much for the reply. >> I don't think Varnish is running on port 80. >> >> When I execute this: netstat -tulpn , I get: >> >> Active Internet connections (only servers) >> Proto Recv-Q Send-Q Local Address Foreign >> Address State PID/Program name >> tcp 0 0 0.0.0.0:3306 0.0.0.0:* >> LISTEN 30222/mysqld >> tcp 0 0 0.0.0.0:587 0.0.0.0:* >> LISTEN 18407/exim >> tcp 0 0 0.0.0.0:110 0.0.0.0:* >> LISTEN 18340/dovecot >> tcp 0 0 127.0.0.1:783 0.0.0.0:* >> LISTEN 18599/spamd.pid --m >> tcp 0 0 0.0.0.0:143 0.0.0.0:* >> LISTEN 18340/dovecot >> tcp 0 0 0.0.0.0:2095 0.0.0.0:* >> LISTEN 1463/cpsrvd (SSL) - >> tcp 0 0 0.0.0.0:80 0.0.0.0:* >> LISTEN 7866/httpd >> tcp 0 0 0.0.0.0:2096 0.0.0.0:* >> LISTEN 1463/cpsrvd (SSL) - >> tcp 0 0 0.0.0.0:465 0.0.0.0:* >> LISTEN 18407/exim >> tcp 0 0 37.61.236.139:49619 0.0.0.0:* >> LISTEN 13118/pure-ftpd (ID >> tcp 0 0 37.61.235.212:53 0.0.0.0:* >> LISTEN 13054/named >> tcp 0 0 37.61.236.139:53 0.0.0.0:* >> LISTEN 13054/named >> tcp 0 0 127.0.0.1:53 0.0.0.0:* >> LISTEN 13054/named >> tcp 0 0 0.0.0.0:21 0.0.0.0:* >> LISTEN 13118/pure-ftpd (ID >> tcp 0 0 0.0.0.0:47926 0.0.0.0:* >> LISTEN 4224/sshd >> tcp 0 0 127.0.0.1:953 0.0.0.0:* >> LISTEN 13054/named >> tcp 0 0 0.0.0.0:25 0.0.0.0:* >> LISTEN 18407/exim >> tcp 0 0 0.0.0.0:443 0.0.0.0:* >> LISTEN 7866/httpd >> tcp 0 0 0.0.0.0:2077 0.0.0.0:* >> LISTEN 25872/cpdavd - acce >> tcp 0 0 0.0.0.0:2078 0.0.0.0:* >> LISTEN 25872/cpdavd - acce >> tcp 0 0 0.0.0.0:993 0.0.0.0:* >> LISTEN 18340/dovecot >> tcp 0 0 0.0.0.0:2082 0.0.0.0:* >> LISTEN 1463/cpsrvd (SSL) - >> tcp 0 0 0.0.0.0:995 0.0.0.0:* >> LISTEN 18340/dovecot >> tcp 0 0 0.0.0.0:2083 0.0.0.0:* >> LISTEN 1463/cpsrvd (SSL) - >> tcp 0 0 0.0.0.0:2086 0.0.0.0:* >> LISTEN 1463/cpsrvd (SSL) - >> tcp 0 0 127.0.0.1:199 0.0.0.0:* >> LISTEN 4360/snmpd >> tcp 0 0 0.0.0.0:2087 0.0.0.0:* >> LISTEN 1463/cpsrvd (SSL) - >> tcp 0 0 :::587 >> :::* LISTEN 18407/exim >> tcp 0 0 :::80 >> :::* LISTEN 7866/httpd >> tcp 0 0 :::465 >> :::* LISTEN 18407/exim >> tcp 0 0 :::21 >> :::* LISTEN 13118/pure-ftpd (ID >> tcp 0 0 :::47926 >> :::* LISTEN 4224/sshd >> tcp 0 0 :::25 >> :::* LISTEN 18407/exim >> tcp 0 0 :::443 >> :::* LISTEN 7866/httpd >> udp 0 0 0.0.0.0:161 0.0.0.0:* >> 4360/snmpd >> udp 0 0 37.61.235.212:53 0.0.0.0:* >> 13054/named >> udp 0 0 37.61.236.139:53 0.0.0.0:* >> 13054/named >> udp 0 0 127.0.0.1:53 0.0.0.0:* >> 13054/named >> udp 0 0 37.61.235.212:123 0.0.0.0:* >> 1130/ntpd >> udp 0 0 37.61.236.139:123 0.0.0.0:* >> 1130/ntpd >> udp 0 0 127.0.0.1:123 0.0.0.0:* >> 1130/ntpd >> udp 0 0 0.0.0.0:123 0.0.0.0:* >> 1130/ntpd >> udp 0 0 fe80::216:3eff:fead:d8c:123 >> :::* 1130/ntpd >> udp 0 0 ::1:123 >> :::* 1130/ntpd >> udp 0 0 :::123 >> :::* 1130/ntpd >> >> >> >>> Excerpts from Joao Rios's message of 2014-05-21 11:11:17 -0700: >>> > I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. >>> > After installing the rpm and follow the installation procedures, >>> > it seems the service fails to start: >>> > >>> > # service varnish restart >>> > Stopping Varnish Cache: [FAILED] >>> > Starting Varnish Cache: [ OK ] >>> >>> No, that indicates that it didn't stop Varnish (probably because it >>> wasn't >>> running), but it *started* it successfully. >>> >>> Have you verified that it is indeed not running (via ps, lsof, etc.)? >>> - P >>> >> >> > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jprr773 at gmail.com Thu May 22 11:50:53 2014 From: jprr773 at gmail.com (Joao Rios) Date: Thu, 22 May 2014 12:50:53 +0100 Subject: Help on Varnish configuration problem on Centos 6.5 In-Reply-To: References: Message-ID: Thank you Per Buer, I admit I am a newbie and this is my first attemp to install Varnish, and I need to read more about Varnish :) So Varnish need to be installed on a different port when apache is running on port 80, and normally what ports are used? Thank you On Thu, May 22, 2014 at 12:46 PM, Per Buer wrote: > Varnish is not running. When it doesn't start you can check syslog. It > will probably say something like "can't bind to port". > > The reason is obvious (for me at least :-). > > tcp 0 0 0.0.0.0:80 0.0.0.0:* > LISTEN 7866/httpd > > You have apache running on port 80 so Varnish can't bind to the port. > > > On Thu, May 22, 2014 at 1:19 PM, Joao Rios wrote: > >> Well, if I : # ps -ef | grep varnishd , >> >> I get this: >> >> root 13560 13314 0 14:18 pts/3 00:00:00 grep varnishd >> >> >> >> On Thu, May 22, 2014 at 12:10 PM, Joao Rios wrote: >> >>> Hi James, >>> Thank you so much for the reply. >>> I don't think Varnish is running on port 80. >>> >>> When I execute this: netstat -tulpn , I get: >>> >>> Active Internet connections (only servers) >>> Proto Recv-Q Send-Q Local Address Foreign >>> Address State PID/Program name >>> tcp 0 0 0.0.0.0:3306 0.0.0.0:* >>> LISTEN 30222/mysqld >>> tcp 0 0 0.0.0.0:587 0.0.0.0:* >>> LISTEN 18407/exim >>> tcp 0 0 0.0.0.0:110 0.0.0.0:* >>> LISTEN 18340/dovecot >>> tcp 0 0 127.0.0.1:783 0.0.0.0:* >>> LISTEN 18599/spamd.pid --m >>> tcp 0 0 0.0.0.0:143 0.0.0.0:* >>> LISTEN 18340/dovecot >>> tcp 0 0 0.0.0.0:2095 0.0.0.0:* >>> LISTEN 1463/cpsrvd (SSL) - >>> tcp 0 0 0.0.0.0:80 0.0.0.0:* >>> LISTEN 7866/httpd >>> tcp 0 0 0.0.0.0:2096 0.0.0.0:* >>> LISTEN 1463/cpsrvd (SSL) - >>> tcp 0 0 0.0.0.0:465 0.0.0.0:* >>> LISTEN 18407/exim >>> tcp 0 0 37.61.236.139:49619 0.0.0.0:* >>> LISTEN 13118/pure-ftpd (ID >>> tcp 0 0 37.61.235.212:53 0.0.0.0:* >>> LISTEN 13054/named >>> tcp 0 0 37.61.236.139:53 0.0.0.0:* >>> LISTEN 13054/named >>> tcp 0 0 127.0.0.1:53 0.0.0.0:* >>> LISTEN 13054/named >>> tcp 0 0 0.0.0.0:21 0.0.0.0:* >>> LISTEN 13118/pure-ftpd (ID >>> tcp 0 0 0.0.0.0:47926 0.0.0.0:* >>> LISTEN 4224/sshd >>> tcp 0 0 127.0.0.1:953 0.0.0.0:* >>> LISTEN 13054/named >>> tcp 0 0 0.0.0.0:25 0.0.0.0:* >>> LISTEN 18407/exim >>> tcp 0 0 0.0.0.0:443 0.0.0.0:* >>> LISTEN 7866/httpd >>> tcp 0 0 0.0.0.0:2077 0.0.0.0:* >>> LISTEN 25872/cpdavd - acce >>> tcp 0 0 0.0.0.0:2078 0.0.0.0:* >>> LISTEN 25872/cpdavd - acce >>> tcp 0 0 0.0.0.0:993 0.0.0.0:* >>> LISTEN 18340/dovecot >>> tcp 0 0 0.0.0.0:2082 0.0.0.0:* >>> LISTEN 1463/cpsrvd (SSL) - >>> tcp 0 0 0.0.0.0:995 0.0.0.0:* >>> LISTEN 18340/dovecot >>> tcp 0 0 0.0.0.0:2083 0.0.0.0:* >>> LISTEN 1463/cpsrvd (SSL) - >>> tcp 0 0 0.0.0.0:2086 0.0.0.0:* >>> LISTEN 1463/cpsrvd (SSL) - >>> tcp 0 0 127.0.0.1:199 0.0.0.0:* >>> LISTEN 4360/snmpd >>> tcp 0 0 0.0.0.0:2087 0.0.0.0:* >>> LISTEN 1463/cpsrvd (SSL) - >>> tcp 0 0 :::587 >>> :::* LISTEN 18407/exim >>> tcp 0 0 :::80 >>> :::* LISTEN 7866/httpd >>> tcp 0 0 :::465 >>> :::* LISTEN 18407/exim >>> tcp 0 0 :::21 >>> :::* LISTEN 13118/pure-ftpd (ID >>> tcp 0 0 :::47926 >>> :::* LISTEN 4224/sshd >>> tcp 0 0 :::25 >>> :::* LISTEN 18407/exim >>> tcp 0 0 :::443 >>> :::* LISTEN 7866/httpd >>> udp 0 0 0.0.0.0:161 0.0.0.0:* >>> 4360/snmpd >>> udp 0 0 37.61.235.212:53 0.0.0.0:* >>> 13054/named >>> udp 0 0 37.61.236.139:53 0.0.0.0:* >>> 13054/named >>> udp 0 0 127.0.0.1:53 0.0.0.0:* >>> 13054/named >>> udp 0 0 37.61.235.212:123 0.0.0.0:* >>> 1130/ntpd >>> udp 0 0 37.61.236.139:123 0.0.0.0:* >>> 1130/ntpd >>> udp 0 0 127.0.0.1:123 0.0.0.0:* >>> 1130/ntpd >>> udp 0 0 0.0.0.0:123 0.0.0.0:* >>> 1130/ntpd >>> udp 0 0 fe80::216:3eff:fead:d8c:123 >>> :::* 1130/ntpd >>> udp 0 0 ::1:123 >>> :::* 1130/ntpd >>> udp 0 0 :::123 >>> :::* 1130/ntpd >>> >>> >>> >>>> Excerpts from Joao Rios's message of 2014-05-21 11:11:17 -0700: >>>> > I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. >>>> > After installing the rpm and follow the installation procedures, >>>> > it seems the service fails to start: >>>> > >>>> > # service varnish restart >>>> > Stopping Varnish Cache: [FAILED] >>>> > Starting Varnish Cache: [ OK ] >>>> >>>> No, that indicates that it didn't stop Varnish (probably because it >>>> wasn't >>>> running), but it *started* it successfully. >>>> >>>> Have you verified that it is indeed not running (via ps, lsof, etc.)? >>>> - P >>>> >>> >>> >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > > > -- > *Per Buer* > CTO | Varnish Software > Phone: +47 958 39 117 | Skype: per.buer > We Make Websites Fly! > > Winner of the Red Herring Top 100 Global Award 2013 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Thu May 22 12:28:04 2014 From: perbu at varnish-software.com (Per Buer) Date: Thu, 22 May 2014 14:28:04 +0200 Subject: Help on Varnish configuration problem on Centos 6.5 In-Reply-To: References: Message-ID: Normally Varnish runs on port 80 for production environment so clients can connect to the default HTTP port. Apache is typically moved to port 8080 but it can of course be any port. On Thu, May 22, 2014 at 1:50 PM, Joao Rios wrote: > Thank you Per Buer, > I admit I am a newbie and this is my first attemp to install Varnish, and > I need to read more about Varnish :) > > So Varnish need to be installed on a different port when apache is running > on port 80, and normally what ports are used? > Thank you > > > > > > On Thu, May 22, 2014 at 12:46 PM, Per Buer wrote: > >> Varnish is not running. When it doesn't start you can check syslog. It >> will probably say something like "can't bind to port". >> >> The reason is obvious (for me at least :-). >> >> tcp 0 0 0.0.0.0:80 >> 0.0.0.0:* LISTEN 7866/httpd >> >> You have apache running on port 80 so Varnish can't bind to the port. >> >> >> On Thu, May 22, 2014 at 1:19 PM, Joao Rios wrote: >> >>> Well, if I : # ps -ef | grep varnishd , >>> >>> I get this: >>> >>> root 13560 13314 0 14:18 pts/3 00:00:00 grep varnishd >>> >>> >>> >>> On Thu, May 22, 2014 at 12:10 PM, Joao Rios wrote: >>> >>>> Hi James, >>>> Thank you so much for the reply. >>>> I don't think Varnish is running on port 80. >>>> >>>> When I execute this: netstat -tulpn , I get: >>>> >>>> Active Internet connections (only servers) >>>> Proto Recv-Q Send-Q Local Address Foreign >>>> Address State PID/Program name >>>> tcp 0 0 0.0.0.0:3306 0.0.0.0:* >>>> LISTEN 30222/mysqld >>>> tcp 0 0 0.0.0.0:587 0.0.0.0:* >>>> LISTEN 18407/exim >>>> tcp 0 0 0.0.0.0:110 0.0.0.0:* >>>> LISTEN 18340/dovecot >>>> tcp 0 0 127.0.0.1:783 0.0.0.0:* >>>> LISTEN 18599/spamd.pid --m >>>> tcp 0 0 0.0.0.0:143 0.0.0.0:* >>>> LISTEN 18340/dovecot >>>> tcp 0 0 0.0.0.0:2095 0.0.0.0:* >>>> LISTEN 1463/cpsrvd (SSL) - >>>> tcp 0 0 0.0.0.0:80 0.0.0.0:* >>>> LISTEN 7866/httpd >>>> tcp 0 0 0.0.0.0:2096 0.0.0.0:* >>>> LISTEN 1463/cpsrvd (SSL) - >>>> tcp 0 0 0.0.0.0:465 0.0.0.0:* >>>> LISTEN 18407/exim >>>> tcp 0 0 37.61.236.139:49619 0.0.0.0:* >>>> LISTEN 13118/pure-ftpd (ID >>>> tcp 0 0 37.61.235.212:53 0.0.0.0:* >>>> LISTEN 13054/named >>>> tcp 0 0 37.61.236.139:53 0.0.0.0:* >>>> LISTEN 13054/named >>>> tcp 0 0 127.0.0.1:53 0.0.0.0:* >>>> LISTEN 13054/named >>>> tcp 0 0 0.0.0.0:21 0.0.0.0:* >>>> LISTEN 13118/pure-ftpd (ID >>>> tcp 0 0 0.0.0.0:47926 0.0.0.0:* >>>> LISTEN 4224/sshd >>>> tcp 0 0 127.0.0.1:953 0.0.0.0:* >>>> LISTEN 13054/named >>>> tcp 0 0 0.0.0.0:25 0.0.0.0:* >>>> LISTEN 18407/exim >>>> tcp 0 0 0.0.0.0:443 0.0.0.0:* >>>> LISTEN 7866/httpd >>>> tcp 0 0 0.0.0.0:2077 0.0.0.0:* >>>> LISTEN 25872/cpdavd - acce >>>> tcp 0 0 0.0.0.0:2078 0.0.0.0:* >>>> LISTEN 25872/cpdavd - acce >>>> tcp 0 0 0.0.0.0:993 0.0.0.0:* >>>> LISTEN 18340/dovecot >>>> tcp 0 0 0.0.0.0:2082 0.0.0.0:* >>>> LISTEN 1463/cpsrvd (SSL) - >>>> tcp 0 0 0.0.0.0:995 0.0.0.0:* >>>> LISTEN 18340/dovecot >>>> tcp 0 0 0.0.0.0:2083 0.0.0.0:* >>>> LISTEN 1463/cpsrvd (SSL) - >>>> tcp 0 0 0.0.0.0:2086 0.0.0.0:* >>>> LISTEN 1463/cpsrvd (SSL) - >>>> tcp 0 0 127.0.0.1:199 0.0.0.0:* >>>> LISTEN 4360/snmpd >>>> tcp 0 0 0.0.0.0:2087 0.0.0.0:* >>>> LISTEN 1463/cpsrvd (SSL) - >>>> tcp 0 0 :::587 >>>> :::* LISTEN 18407/exim >>>> tcp 0 0 :::80 >>>> :::* LISTEN 7866/httpd >>>> tcp 0 0 :::465 >>>> :::* LISTEN 18407/exim >>>> tcp 0 0 :::21 >>>> :::* LISTEN 13118/pure-ftpd (ID >>>> tcp 0 0 :::47926 >>>> :::* LISTEN 4224/sshd >>>> tcp 0 0 :::25 >>>> :::* LISTEN 18407/exim >>>> tcp 0 0 :::443 >>>> :::* LISTEN 7866/httpd >>>> udp 0 0 0.0.0.0:161 0.0.0.0:* >>>> 4360/snmpd >>>> udp 0 0 37.61.235.212:53 0.0.0.0:* >>>> 13054/named >>>> udp 0 0 37.61.236.139:53 0.0.0.0:* >>>> 13054/named >>>> udp 0 0 127.0.0.1:53 0.0.0.0:* >>>> 13054/named >>>> udp 0 0 37.61.235.212:123 0.0.0.0:* >>>> 1130/ntpd >>>> udp 0 0 37.61.236.139:123 0.0.0.0:* >>>> 1130/ntpd >>>> udp 0 0 127.0.0.1:123 0.0.0.0:* >>>> 1130/ntpd >>>> udp 0 0 0.0.0.0:123 0.0.0.0:* >>>> 1130/ntpd >>>> udp 0 0 fe80::216:3eff:fead:d8c:123 >>>> :::* 1130/ntpd >>>> udp 0 0 ::1:123 >>>> :::* 1130/ntpd >>>> udp 0 0 :::123 >>>> :::* 1130/ntpd >>>> >>>> >>>> >>>>> Excerpts from Joao Rios's message of 2014-05-21 11:11:17 -0700: >>>>> > I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. >>>>> > After installing the rpm and follow the installation procedures, >>>>> > it seems the service fails to start: >>>>> > >>>>> > # service varnish restart >>>>> > Stopping Varnish Cache: [FAILED] >>>>> > Starting Varnish Cache: [ OK ] >>>>> >>>>> No, that indicates that it didn't stop Varnish (probably because it >>>>> wasn't >>>>> running), but it *started* it successfully. >>>>> >>>>> Have you verified that it is indeed not running (via ps, lsof, etc.)? >>>>> - P >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> varnish-misc mailing list >>> varnish-misc at varnish-cache.org >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>> >> >> >> >> -- >> *Per Buer* >> CTO | Varnish Software >> Phone: +47 958 39 117 | Skype: per.buer >> We Make Websites Fly! >> >> Winner of the Red Herring Top 100 Global Award 2013 >> >> >> > -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrbits.dcf at gmail.com Thu May 22 12:36:54 2014 From: mrbits.dcf at gmail.com (MrBiTs) Date: Thu, 22 May 2014 09:36:54 -0300 Subject: Help on Varnish configuration problem on Centos 6.5 In-Reply-To: References: Message-ID: <537DEF66.5030609@gmail.com> On 05/22/2014 08:50 AM, Joao Rios wrote: > Thank you Per Buer, > I admit I am a newbie and this is my first attemp to install Varnish, and I need to read more about Varnish :) > > So Varnish need to be installed on a different port when apache is running on port 80, and normally what ports are used? > Thank you Au contrair, Apache should run on another port (maybe 8080 ?) and varnish, that will receive HTTP requests to cache them, runing on port 80. -- echo 920680245503158263821824753325972325831728150312428342077412537729420364909318736253880971145983128276953696631956862757408858710644955909208239222408534030331747172248238293509539472164571738870818862971439246497991147436431430964603600458631758354381402352368220521740203494788796697543569807851284795072334480481413675418412856581412376640379241258356436205061541557366641602992820546646995466P | dc From jprr773 at gmail.com Thu May 22 16:34:16 2014 From: jprr773 at gmail.com (Joao Rios) Date: Thu, 22 May 2014 17:34:16 +0100 Subject: Help on Varnish configuration problem on Centos 6.5 Message-ID: I finally managed to configure Varnish properly!! Thank you very much to all. Have a great one! Joao -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabio at dataspace.com.br Thu May 22 16:38:17 2014 From: fabio at dataspace.com.br (Fabio Fraga [DS]) Date: Thu, 22 May 2014 13:38:17 -0300 Subject: Help on Varnish configuration problem on Centos 6.5 In-Reply-To: References: Message-ID: (Y) Congrats. Fabio On May 22, 2014 1:34 PM, "Joao Rios" wrote: > I finally managed to configure Varnish properly!! > Thank you very much to all. > Have a great one! > Joao > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nemolee888 at gmail.com Fri May 23 01:18:48 2014 From: nemolee888 at gmail.com (=?UTF-8?B?5p2O5a2m5by6?=) Date: Fri, 23 May 2014 09:18:48 +0800 Subject: varnish-misc Digest, Vol 98, Issue 35 In-Reply-To: References: Message-ID: <537EA1F8.8080100@gmail.com> Hello Joao: You can use the flow command to check the syntax error. #varnishd -C -f default.vcl -n /tmp/tmp >/dev/null && echo "Syntax ok" or: /etc/init.d/varnish configtest nemo ? 2014-5-22 18:00, varnish-misc-request at varnish-cache.org ??: > Send varnish-misc mailing list submissions to > varnish-misc at varnish-cache.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > or, via email, send a message with subject or body 'help' to > varnish-misc-request at varnish-cache.org > > You can reach the person managing the list at > varnish-misc-owner at varnish-cache.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of varnish-misc digest..." > > > Today's Topics: > > 1. Re: Help on Varnish configuration problem on Centos 6.5 > (Joao Rios) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 May 2014 10:50:02 +0100 > From: Joao Rios > To: varnish-misc at varnish-cache.org > Subject: Re: Help on Varnish configuration problem on Centos 6.5 > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hello F?bio, > > Thank you very much for the reply. > I'm newbie with Varnish and I'm looking at the output > using # varnishd -C -f /etc/varnish/default.vcl > but can't really say what's wrong with it... > Can I copy the output here? > Obrigado :) > > Joao > > > > On Thu, May 22, 2014 at 2:37 AM, wrote: > >> Send varnish-misc mailing list submissions to >> varnish-misc at varnish-cache.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> or, via email, send a message with subject or body 'help' to >> varnish-misc-request at varnish-cache.org >> >> You can reach the person managing the list at >> varnish-misc-owner at varnish-cache.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of varnish-misc digest..." >> >> >> Today's Topics: >> >> 1. Re: Help on Varnish configuration problem on Centos 6.5 >> (James Pearson) >> 2. Re: Varnish 4 - VCL Compilation failed - Valid VCL (James Pearson) >> 3. about hitrate (???) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 21 May 2014 11:31:47 -0700 >> From: James Pearson >> To: varnish-misc >> Subject: Re: Help on Varnish configuration problem on Centos 6.5 >> Message-ID: <1400697022-sup-4433 at geror.local> >> Content-Type: text/plain; charset="utf-8" >> >> Excerpts from Joao Rios's message of 2014-05-21 11:11:17 -0700: >>> I am trying to run Varnish 3.0.5 on Centos 6.5 with no sucess. >>> After installing the rpm and follow the installation procedures, >>> it seems the service fails to start: >>> >>> # service varnish restart >>> Stopping Varnish Cache: [FAILED] >>> Starting Varnish Cache: [ OK ] >> No, that indicates that it didn't stop Varnish (probably because it wasn't >> running), but it *started* it successfully. >> >> Have you verified that it is indeed not running (via ps, lsof, etc.)? >> - P >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: signature.asc >> Type: application/pgp-signature >> Size: 819 bytes >> Desc: not available >> URL: < >> https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140521/f98185a4/attachment-0001.pgp >> ------------------------------ >> >> Message: 2 >> Date: Wed, 21 May 2014 11:37:54 -0700 >> From: James Pearson >> To: varnish-misc >> Subject: Re: Varnish 4 - VCL Compilation failed - Valid VCL >> Message-ID: <1400697383-sup-6303 at geror.local> >> Content-Type: text/plain; charset="utf-8" >> >> Excerpts from Hugues Alary's message of 2014-05-20 21:57:49 -0700: >>> My guess is that when varnishd is runs, it switches from root to nobody, >>> and nobody doesn't have the right permissions for that directory. >> I don't know about compilation, but in Varnish 3 the -u and -g options >> control >> the user and group to which Varnish will drop. >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: signature.asc >> Type: application/pgp-signature >> Size: 819 bytes >> Desc: not available >> URL: < >> https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140521/5a9e259a/attachment-0001.pgp >> ------------------------------ >> >> Message: 3 >> Date: Thu, 22 May 2014 09:36:49 +0800 >> From: ??? >> To: varnish-misc at varnish-cache.org >> Subject: about hitrate >> Message-ID: <537D54B1.4090606 at gmail.com> >> Content-Type: text/plain; charset="gb2312" >> >> Hello everyone: >> I am a newbie of varnish 4.0 . Can I check the hitrate in the >> varnishstat command? This command's output is diffrent from version 3.0. >> Thank you! >> >> -- >> >> *???? ? ???* >> >> ? ????????????512? >> >> Tel:(+86-411)84799089 >> >> Mobile: 18041169612 >> >> Email: lixueqiang at chinafesco.com >> >> http://www.chinafesco.com/ >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140522/2f5370a9/attachment.html >> ------------------------------ >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> >> End of varnish-misc Digest, Vol 98, Issue 33 >> ******************************************** >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > End of varnish-misc Digest, Vol 98, Issue 35 > ******************************************** -- *???? ? ???* ? ????????????512? Tel:(+86-411)84799089 Mobile: 18041169612 Email: lixueqiang at chinafesco.com http://www.chinafesco.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nemolee888 at gmail.com Fri May 23 01:38:49 2014 From: nemolee888 at gmail.com (=?UTF-8?B?5p2O5a2m5by6?=) Date: Fri, 23 May 2014 09:38:49 +0800 Subject: varnish-misc Digest, Vol 98, Issue 34 In-Reply-To: References: Message-ID: <537EA6A9.4010602@gmail.com> Hello Andrew: You are a good guy, I think . Fllow your ticks ,I have reslovd the problem . Because I have nothing config to do ,So the varnish command have no output about hit rate. After I config the default.vcl file ,every thing is ok . Thank you very much . ? 2014-5-22 16:46, varnish-misc-request at varnish-cache.org ??: > Send varnish-misc mailing list submissions to > varnish-misc at varnish-cache.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > or, via email, send a message with subject or body 'help' to > varnish-misc-request at varnish-cache.org > > You can reach the person managing the list at > varnish-misc-owner at varnish-cache.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of varnish-misc digest..." > > > Today's Topics: > > 1. Re: about hitrate (Andrew Langhorn) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 May 2014 09:46:28 +0100 > From: Andrew Langhorn > To: varnish-misc at varnish-cache.org, ??? > Subject: Re: about hitrate > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi, > > I think you should be able to use varnishtop and varnishlog to achieve what you?re after. > > varnishtop will let you see which URLs are hitting your backend(s) most often. Something like varnishtop -i txurl might be a good starting point, although the docs[1] have some further details on its use. > > varnishlog will let you search your logs for a given URL to look at the request. varnishlog -c -m ?RxURL:^/foo/bar? will show you requests from client (-c) for /foo/bar > > Andrew > > [1]?https://www.varnish-cache.org/docs/4.0/users-guide/operation-statistics.html#users-guide-statistics > On 22 May 2014 at 02:39:38, ??? (nemolee888 at gmail.com) wrote: > > Hello everyone: > ??? I am a newbie of varnish 4.0 . Can I check the hitrate in the varnishstat command? This command's output is diffrent from version 3.0. > ??? Thank you! > > -- > ? > > ???? ? ????? > > ? ????????????512? > > Tel:(+86-411)84799089 > > Mobile: 18041169612 > > Email: lixueqiang at chinafesco.com > > http://www.chinafesco.com/ > > ? > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > End of varnish-misc Digest, Vol 98, Issue 34 > ******************************************** From andrew.langhorn at digital.cabinet-office.gov.uk Fri May 23 11:54:35 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Fri, 23 May 2014 12:54:35 +0100 Subject: varnish-misc Digest, Vol 98, Issue 34 In-Reply-To: <537EA6A9.4010602@gmail.com> References: <537EA6A9.4010602@gmail.com> Message-ID: Glad to help, and happy to see you?ve got it working :) On 23 May 2014 at 02:42:15, ??? (nemolee888 at gmail.com) wrote: Hello Andrew: You are a good guy, I think . Fllow your ticks ,I have reslovd the problem . Because I have nothing config to do ,So the varnish command have no output about hit rate. After I config the default.vcl file ,every thing is ok . Thank you very much . ? 2014-5-22 16:46, varnish-misc-request at varnish-cache.org ??: > Send varnish-misc mailing list submissions to > varnish-misc at varnish-cache.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > or, via email, send a message with subject or body 'help' to > varnish-misc-request at varnish-cache.org > > You can reach the person managing the list at > varnish-misc-owner at varnish-cache.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of varnish-misc digest..." > > > Today's Topics: > > 1. Re: about hitrate (Andrew Langhorn) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 May 2014 09:46:28 +0100 > From: Andrew Langhorn > To: varnish-misc at varnish-cache.org, ??? > Subject: Re: about hitrate > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi, > > I think you should be able to use varnishtop and varnishlog to achieve what you?re after. > > varnishtop will let you see which URLs are hitting your backend(s) most often. Something like varnishtop -i txurl might be a good starting point, although the docs[1] have some further details on its use. > > varnishlog will let you search your logs for a given URL to look at the request. varnishlog -c -m ?RxURL:^/foo/bar? will show you requests from client (-c) for /foo/bar > > Andrew > > [1]?https://www.varnish-cache.org/docs/4.0/users-guide/operation-statistics.html#users-guide-statistics > On 22 May 2014 at 02:39:38, ??? (nemolee888 at gmail.com) wrote: > > Hello everyone: > ??? I am a newbie of varnish 4.0 . Can I check the hitrate in the varnishstat command? This command's output is diffrent from version 3.0. > ??? Thank you! > > -- > ? > > ???? ? ????? > > ? ????????????512? > > Tel:(+86-411)84799089 > > Mobile: 18041169612 > > Email: lixueqiang at chinafesco.com > > http://www.chinafesco.com/ > > ? > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > End of varnish-misc Digest, Vol 98, Issue 34 > ******************************************** _______________________________________________ varnish-misc mailing list varnish-misc at varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From japrice at gmail.com Sun May 25 18:11:54 2014 From: japrice at gmail.com (Jason Price) Date: Sun, 25 May 2014 14:11:54 -0400 Subject: varnishhist varient: show TxStatus in histogram form? Message-ID: Doing a bunch of load testing with new code. I'm trying to get visibility into http codes. Most of the time Varnish isn't responsible for the errors, but it'd be nice to have visibility into: || || + || + + || + + =========================== 200 503v 503b ..... where 503v indicates varnish sent the 503 due to backend timeout, or 503b where the backend delivered the 503 to varnish. At high load, efficiently parsing varnishlog output is rather a pain... it'd be nice if varnish did it itself.... From yamakasi.014 at gmail.com Tue May 27 21:45:52 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 27 May 2014 23:45:52 +0200 Subject: Libc Error with Vmod-dbrw Message-ID: Hi, I'm testing the Vmod-dbrw module on 3.0.2 on Ubuntu which gives me the following error on starting Varnish: May 27 12:17:46 proxy-01 varnishd[1414]: Pushing vcls failed:#012CLI communication error (hdr) kernel: [ 616.137618] varnishd[1659]: segfault at 0 ip 00007f56f8084ad4 sp 00007fffff54ae70 error 4 in libc-2.15.so[7f56f8048000+1b5000] It seem that this happens when I add whatever like this in my vcl file: sub vcl_init { dbrw.config("mysql", "server=db.example.com;database=varnish;user=varnish;password=guessme", "SELECT dest,pattern,value FROM rewrite WHERE host='$host' and '$url' like url"); } Can anyone help me out here ? I also informed the developer of this module. Thanks. Matt From jan at architechs.eu Tue May 27 22:51:53 2014 From: jan at architechs.eu (=?utf-8?B?SmFuLUFhZ2UgRnJ5ZGVuYsO4LUJydXZvbGw=?=) Date: Tue, 27 May 2014 22:51:53 +0000 Subject: Libc Error with Vmod-dbrw In-Reply-To: References: Message-ID: Are you sure the query shouldn't rather be ... url like '$url' ? Best regards Jan Sent from my phone - please excuse the brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoloseem at gmail.com Wed May 28 06:30:43 2014 From: yoloseem at gmail.com (=?UTF-8?B?6rmA7ZiE7KSA?=) Date: Wed, 28 May 2014 15:30:43 +0900 Subject: Varnish 3.2 obj.hits count bug Message-ID: Hi, I'm experiencing weird behaviour of obj.hits value. It seems that it started from 1, not zero, when the object wasn't in the cache. and it increases twice as 3, 5, 7, 9, .... Is this normal? Any help or suggestion is welcome! Regards, Hyunjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Wed May 28 06:31:06 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Wed, 28 May 2014 08:31:06 +0200 Subject: Libc Error with Vmod-dbrw In-Reply-To: References: Message-ID: Hi, I have seen that too and I'm quite sure I also used an another example where it was set right. I will test it out. Thanks, Matt 2014-05-28 0:51 GMT+02:00 Jan-Aage Frydenb?-Bruvoll : > Are you sure the query shouldn't rather be ... url like '$url' ? > > Best regards > Jan > > Sent from my phone - please excuse the brevity. From yoloseem at gmail.com Wed May 28 07:27:19 2014 From: yoloseem at gmail.com (=?UTF-8?B?6rmA7ZiE7KSA?=) Date: Wed, 28 May 2014 16:27:19 +0900 Subject: Varnish 3.2 obj.hits count bug In-Reply-To: References: Message-ID: Hi. I've got this problem. It seems that it was caused by Chrome browser's prefetching. obj.hits normally counts up from zero via cURL test. 2014-05-28 15:30 GMT+09:00 ??? : > Hi, I'm experiencing weird behaviour of obj.hits value. > > It seems that it started from 1, not zero, when the object wasn't in the > cache. and it increases twice as 3, 5, 7, 9, .... > > Is this normal? > Any help or suggestion is welcome! > > Regards, > Hyunjun > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkarsten at varnish-software.com Wed May 28 07:44:51 2014 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Wed, 28 May 2014 09:44:51 +0200 Subject: Signed RPM Packages In-Reply-To: References: <46085FDC-43C6-4DD0-A15B-8057194A4D43@jasonwoods.me.uk> Message-ID: <20140528074450.GA3533@immer.varnish-software.com> [ A bit late to the party, sorry. ] On Fri, May 16, 2014 at 07:55:30PM +0200, Per Buer wrote: > On Fri, May 16, 2014 at 6:16 PM, Jason Woods wrote: [..] > > But noticed that the GPG signature checking of the RPMs was not enabled, > > and the RPMs were transferred over plaintext HTTP! [..] > Lasse might have more information wrt to the state of the packages right > now. I know he has been working on the RPMs quite a bit lately. The plan is to start signing RPMs with the upcoming 4.0.1 release. We won't introduce this in 3.0 this late in its lifetime. Please use HTTPS when installing them. -- Lasse Karstensen with Varnish release manager hat From yamakasi.014 at gmail.com Wed May 28 07:56:36 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Wed, 28 May 2014 09:56:36 +0200 Subject: Libc Error with Vmod-dbrw In-Reply-To: References: Message-ID: Hi, I tested this out again with another query from the docs but it doesn't work and I get the same error. I wonder also why it doesn't debug with the debug option. Cheers, Matt 2014-05-28 8:31 GMT+02:00 Matt . : > Hi, > > I have seen that too and I'm quite sure I also used an another > example where it was set right. I will test it out. > > Thanks, > > Matt > > 2014-05-28 0:51 GMT+02:00 Jan-Aage Frydenb?-Bruvoll : >> Are you sure the query shouldn't rather be ... url like '$url' ? >> >> Best regards >> Jan >> >> Sent from my phone - please excuse the brevity. From lkarsten at varnish-software.com Wed May 28 08:00:21 2014 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Wed, 28 May 2014 10:00:21 +0200 Subject: Migrating v3 to v4: How to efectively detect a cache miss in VCL? In-Reply-To: <20140514091546.GA4451@tydirium.the-staging.com> References: <20140514091546.GA4451@tydirium.the-staging.com> Message-ID: <20140528080021.GB3533@immer.varnish-software.com> On Wed, May 14, 2014 at 11:15:47AM +0200, Carlos Pe?as wrote: > Hi. I'm starting the tests to migrate to v4 and I have an issue setting > headers to detect the HIT/MISS. The best way to do this is to look at the X-Varnish header. Example from 4.0: X-Varnish: 98647 X-Varnish: 98650 98648 If it contains one number it is a cache miss, if it has two numbers it was a hit. -- Lasse Karstensen From marco at nucleus.it Wed May 28 12:09:03 2014 From: marco at nucleus.it (marco at nucleus.it) Date: Wed, 28 May 2014 14:09:03 +0200 Subject: Varnish log where obj are stored Message-ID: <20140528140903.2b2b6a31@lobo.lobo.dom> Hi, using more than one storage like -s othersram=malloc,500M -s testram=malloc,50M how can i check from the varnishlog or other tools where the object is storage in cache ? I know that i can force the storage in vcl_fetch with set beresp.storage = "name_og_the_storage"; but how can i verify this ? Thanks Marco From cdumouli at akamai.com Wed May 28 18:13:44 2014 From: cdumouli at akamai.com (Dumoulin, Christopher) Date: Wed, 28 May 2014 13:13:44 -0500 Subject: Dynamic backend based on request header Message-ID: I'd like to have Varnish forward a request to a specific IP and that IP will be specified in a request header. The list of possible backend IPs isn't available ahead of time, so I can't statically define a backend list. Is this possible? Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Wed May 28 19:02:31 2014 From: perbu at varnish-software.com (Per Buer) Date: Wed, 28 May 2014 21:02:31 +0200 Subject: Dynamic backend based on request header In-Reply-To: References: Message-ID: Hi Chris. On Wed, May 28, 2014 at 8:13 PM, Dumoulin, Christopher wrote: > I'd like to have Varnish forward a request to a specific IP and that IP > will be specified in a request header. The list of possible backend IPs > isn't available ahead of time, so I can't statically define a backend list. > Is this possible? > This is currently not possible in a meaningful way. (We're planning on getting there but no ETA exists ATM). Sorry, Per. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cello86 at gmail.com Wed May 28 19:32:20 2014 From: cello86 at gmail.com (cello86) Date: Wed, 28 May 2014 21:32:20 +0200 Subject: No subject Message-ID: <5t92397swkd0031m26xu4drf.1401305357248@email.android.com> Hi,? On my varnish 3 installation i used the remove statement to strip out from responde header the Via and other detectives. if i try to move my configuration on varnish 4 during the syntax check i noticed an error.? could this directive be removed on varnish 4? thanks,? Marcello Inviato da Samsung Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdzstz at gmail.com Wed May 28 23:05:33 2014 From: jdzstz at gmail.com (jdzstz) Date: Thu, 29 May 2014 01:05:33 +0200 Subject: Need step by step document for windows executions In-Reply-To: <1BBA504926243F458E98D3E34698CB45397A4DC7@BANGMAIL01.sapient.com> References: <1BBA504926243F458E98D3E34698CB45397A4DC7@BANGMAIL01.sapient.com> Message-ID: <53866BBD.2050208@gmail.com> Hi Mahesh, About Varnish on Windows, you can read: https://www.varnish-cache.org/trac/wiki/VarnishOnCygwinWindows You have to install Cygwin + Varnish package at your windows. It is not suitable for production environment, it has not been tested at real environments! /*Install Full Cygwin environment with varnish package*//*? *// / /The tar.xz package file is installed inside Cygwin environment using cygwin installer: / * /32 bits installer: //http://cygwin.com/setup-x86.exe/ * /64 bits installer: //http://cygwin.com/setup-x86_64.exe/ /Follow this steps: / * /Download setup-x64.exe (32 bits) or setup-x86_64.exe (64 bits) at localhost / * /Install CYGWIN enviroment executing installer / * /Option one: / o /On package selection list, select "varnish" package from package list in Web category, package will be download from cygwin servers. / o /See: //http://downloads.sourceforge.net/project/cygvarnish/cygport-packages/varnish-package-selection.png/ * /Option two: / o /Download cygport varnish-*.tar.xz varnish package files from //https://sourceforge.net/projects/cygvarnish/files/cygport-packages// o /Execute "setup.exe", select "Install from Local Directory" and select path where *.tar.xz files are located. / El 15/05/2014 13:42, Mahesh Narsappa Bubanale escribi?: > > Hi, > > I am new to Varnish and doing some demo project. > > I need very informative document to execute Varnish on Windows and > also need more information to execute caching mechanism on my application. > > Regards, > > Mahesh Bubanale > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbubanale at sapient.com Thu May 29 04:41:24 2014 From: mbubanale at sapient.com (Mahesh Narsappa Bubanale) Date: Thu, 29 May 2014 04:41:24 +0000 Subject: Need step by step document for windows executions In-Reply-To: <53866BBD.2050208@gmail.com> References: <1BBA504926243F458E98D3E34698CB45397A4DC7@BANGMAIL01.sapient.com> <53866BBD.2050208@gmail.com> Message-ID: <1BBA504926243F458E98D3E34698CB45397ABB5E@BANGMAIL01.sapient.com> Thank you ...I done that part but now I am struck how to check varnishlog on windows .. if anyone can help that will be great. I know on linux we can do all possible but my application run on windows and have restriction to connect or create vm . So struggling .. Please share your though about Varnishlog on windows. Thanks & Regards, Mahesh Bubanale From: varnish-misc-bounces+mbubanale=sapient.com at varnish-cache.org [mailto:varnish-misc-bounces+mbubanale=sapient.com at varnish-cache.org] On Behalf Of jdzstz Sent: Thursday, May 29, 2014 4:36 AM To: varnish-misc at varnish-cache.org Subject: Re: Need step by step document for windows executions Hi Mahesh, About Varnish on Windows, you can read: https://www.varnish-cache.org/trac/wiki/VarnishOnCygwinWindows You have to install Cygwin + Varnish package at your windows. It is not suitable for production environment, it has not been tested at real environments! Install Full Cygwin environment with varnish package ? The tar.xz package file is installed inside Cygwin environment using cygwin installer: * 32 bits installer: http://cygwin.com/setup-x86.exe * 64 bits installer: http://cygwin.com/setup-x86_64.exe Follow this steps: * Download setup-x64.exe (32 bits) or setup-x86_64.exe (64 bits) at localhost * Install CYGWIN enviroment executing installer * Option one: * On package selection list, select "varnish" package from package list in Web category, package will be download from cygwin servers. * See: http://downloads.sourceforge.net/project/cygvarnish/cygport-packages/varnish-package-selection.png * Option two: * Download cygport varnish-*.tar.xz varnish package files from https://sourceforge.net/projects/cygvarnish/files/cygport-packages/ * Execute "setup.exe", select "Install from Local Directory" and select path where *.tar.xz files are located. El 15/05/2014 13:42, Mahesh Narsappa Bubanale escribi?: Hi, I am new to Varnish and doing some demo project. I need very informative document to execute Varnish on Windows and also need more information to execute caching mechanism on my application. Regards, Mahesh Bubanale _______________________________________________ varnish-misc mailing list varnish-misc at varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc ________________________________ [http://static.avast.com/emails/avast-mail-stamp.png] This email is free from viruses and malware because avast! Antivirus protection is active. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.carrillo at gmail.com Thu May 29 09:19:49 2014 From: daniel.carrillo at gmail.com (Daniel Carrillo) Date: Thu, 29 May 2014 11:19:49 +0200 Subject: No subject In-Reply-To: <5t92397swkd0031m26xu4drf.1401305357248@email.android.com> References: <5t92397swkd0031m26xu4drf.1401305357248@email.android.com> Message-ID: 2014-05-28 21:32 GMT+02:00 cello86 : > Hi, > On my varnish 3 installation i used the remove statement to strip out from > responde header the Via and other detectives. > > if i try to move my configuration on varnish 4 during the syntax check i > noticed an error. > > could this directive be removed on varnish 4? > Yes, it was removed: https://www.varnish-cache.org/docs/trunk/whats-new/upgrading.html#the-remove-keyword-is-gone I suggest you to reading the entire article. Kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at ifixit.com Thu May 29 17:30:39 2014 From: james at ifixit.com (James Pearson) Date: Thu, 29 May 2014 10:30:39 -0700 Subject: Need step by step document for windows executions In-Reply-To: <1BBA504926243F458E98D3E34698CB45397ABB5E@BANGMAIL01.sapient.com> References: <1BBA504926243F458E98D3E34698CB45397A4DC7@BANGMAIL01.sapient.com> <53866BBD.2050208@gmail.com> <1BBA504926243F458E98D3E34698CB45397ABB5E@BANGMAIL01.sapient.com> Message-ID: <1401384570-sup-7900@geror.local> Excerpts from Mahesh Narsappa Bubanale's message of 2014-05-28 21:41:24 -0700: > Thank you ...I done that part but now I am struck how to check varnishlog on > windows .. if anyone can help that will be great. What have you tried? What works, and what doesn't? How do the parts that don't work, not work? - P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mbubanale at sapient.com Thu May 29 18:09:43 2014 From: mbubanale at sapient.com (Mahesh Narsappa Bubanale) Date: Thu, 29 May 2014 18:09:43 +0000 Subject: Need step by step document for windows executions In-Reply-To: <1401384570-sup-7900@geror.local> References: <1BBA504926243F458E98D3E34698CB45397A4DC7@BANGMAIL01.sapient.com> <53866BBD.2050208@gmail.com> <1BBA504926243F458E98D3E34698CB45397ABB5E@BANGMAIL01.sapient.com> <1401384570-sup-7900@geror.local> Message-ID: <1BBA504926243F458E98D3E34698CB45397AC3AC@BANGMAIL01.sapient.com> Hi James, Varnish service work but other tools like varnishlog(very important tool) , varnishtop and varnishstat did not work. Thanks , Mahesh Bubanale -----Original Message----- From: varnish-misc-bounces+mbubanale=sapient.com at varnish-cache.org [mailto:varnish-misc-bounces+mbubanale=sapient.com at varnish-cache.org] On Behalf Of James Pearson Sent: Thursday, May 29, 2014 11:01 PM To: varnish-misc Subject: RE: Need step by step document for windows executions Excerpts from Mahesh Narsappa Bubanale's message of 2014-05-28 21:41:24 -0700: > Thank you ...I done that part but now I am struck how to check varnishlog on > windows .. if anyone can help that will be great. What have you tried? What works, and what doesn't? How do the parts that don't work, not work? - P From bluethundr at gmail.com Fri May 30 19:53:04 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Fri, 30 May 2014 15:53:04 -0400 Subject: host is lagging Message-ID: hey all, A couple of the web servers out of a farm of 6 machines we're load balancing with varnish is showing high cpu use. We're balancing them using the round robin LB scheme. I was just wondering if there are any varnish based tools (varnishstat, varnishlog, varnishtop or something else) that might be able to tell me which hosts are underperforming. Also I was wondering if maybe there might be a better scheme to try (like least-conn?) that might be better for alleviating high CPU usage or high load? Thanks Tim -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: From bluethundr at gmail.com Fri May 30 20:03:39 2014 From: bluethundr at gmail.com (Tim Dunphy) Date: Fri, 30 May 2014 16:03:39 -0400 Subject: host is lagging In-Reply-To: References: Message-ID: Ideally what I'd also like to be able to do is use a varnish based tool to find out which HTTP requests are going to which hosts in the load balancing pool. And if such a thing is possible how to do this. Thanks Tim On Fri, May 30, 2014 at 3:53 PM, Tim Dunphy wrote: > hey all, > > A couple of the web servers out of a farm of 6 machines we're load > balancing with varnish is showing high cpu use. We're balancing them using > the round robin LB scheme. I was just wondering if there are any varnish > based tools (varnishstat, varnishlog, varnishtop or something else) that > might be able to tell me which hosts are underperforming. > > Also I was wondering if maybe there might be a better scheme to try (like > least-conn?) that might be better for alleviating high CPU usage or high > load? > > Thanks > Tim > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > -- GPG me!! gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B -------------- next part -------------- An HTML attachment was scrubbed... URL: