From varnish-bugs at varnish-cache.org Sun Dec 2 14:38:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 02 Dec 2012 14:38:16 -0000 Subject: [Varnish] #1234: varnish is really cool Message-ID: <047.24a5ed6ac3febb12e2507b8f9141dfa0@varnish-cache.org> #1234: varnish is really cool -----------------------+-------------------- Reporter: funnyjune | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -----------------------+-------------------- This is just a test ticket, testing varnish script. [http://goo.gl/JumDi funny quotes] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Dec 2 14:45:49 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 02 Dec 2012 14:45:49 -0000 Subject: [Varnish] #1234: varnish is really cool In-Reply-To: <047.24a5ed6ac3febb12e2507b8f9141dfa0@varnish-cache.org> References: <047.24a5ed6ac3febb12e2507b8f9141dfa0@varnish-cache.org> Message-ID: <062.2df846fb1970b293edfeccba61775066@varnish-cache.org> #1234: varnish is really cool -----------------------+---------------------- Reporter: funnyjune | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | -----------------------+---------------------- Changes (by phk): * status: new => closed * resolution: => invalid Old description: > This is just a test ticket, testing varnish script. > [http://goo.gl/JumDi funny quotes] New description: Spam removed. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 10:58:47 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 10:58:47 -0000 Subject: [Varnish] #1233: 404 in documentation In-Reply-To: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> References: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> Message-ID: <061.c282f1a0176adbd7f22398e60028024d@varnish-cache.org> #1233: 404 in documentation ---------------------------+-------------------- Reporter: lkarsten | Owner: Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: minor | Resolution: Keywords: | ---------------------------+-------------------- Comment (by Tollef Fog Heen ): In [d4f456f0326d02a94aed5c0b8143e77f6d180dc9]: {{{ #!CommitTicketReference repository="" revision="d4f456f0326d02a94aed5c0b8143e77f6d180dc9" Stop referencing the module index, since no such thing exists Fixes #1233 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 10:58:48 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 10:58:48 -0000 Subject: [Varnish] #1233: 404 in documentation In-Reply-To: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> References: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> Message-ID: <061.381e1545c263b732283117a57b171ad7@varnish-cache.org> #1233: 404 in documentation ---------------------------+--------------------- Reporter: lkarsten | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: minor | Resolution: fixed Keywords: | ---------------------------+--------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [d4f456f0326d02a94aed5c0b8143e77f6d180dc9]) Stop referencing the module index, since no such thing exists Fixes #1233 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 11:01:45 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 11:01:45 -0000 Subject: [Varnish] #1233: 404 in documentation In-Reply-To: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> References: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> Message-ID: <061.9e3199b2c8a048286d3a226887164cbc@varnish-cache.org> #1233: 404 in documentation ---------------------------+--------------------- Reporter: lkarsten | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: minor | Resolution: fixed Keywords: | ---------------------------+--------------------- Comment (by Tollef Fog Heen ): In [8762363b9ec1eeca715f97eae0189759075a8c2a]: {{{ #!CommitTicketReference repository="" revision="8762363b9ec1eeca715f97eae0189759075a8c2a" Stop referencing the module index, since no such thing exists Fixes #1233 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 11:01:46 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 11:01:46 -0000 Subject: [Varnish] #1233: 404 in documentation In-Reply-To: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> References: <046.0888adfe5b1d7998819f318bcce84c60@varnish-cache.org> Message-ID: <061.097d30711ae487f4be4085dc068c53bb@varnish-cache.org> #1233: 404 in documentation ---------------------------+--------------------- Reporter: lkarsten | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: minor | Resolution: fixed Keywords: | ---------------------------+--------------------- Comment (by Tollef Fog Heen ): (In [8762363b9ec1eeca715f97eae0189759075a8c2a]) Stop referencing the module index, since no such thing exists Fixes #1233 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 11:27:56 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 11:27:56 -0000 Subject: [Varnish] #1230: Refine header check in bin/varnishd/mgt/mgt.h, mgt_main.c for uClibc In-Reply-To: <063.8a6a26f2ac3f22ccc5cb61cb06eda31f@varnish-cache.org> References: <063.8a6a26f2ac3f22ccc5cb61cb06eda31f@varnish-cache.org> Message-ID: <078.75fbdc86504c75971c1b63874b0b2b05@varnish-cache.org> #1230: Refine header check in bin/varnishd/mgt/mgt.h, mgt_main.c for uClibc ----------------------+-------------------- Reporter: basile@? | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk * component: build => varnishd -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 11:35:34 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 11:35:34 -0000 Subject: [Varnish] #1197: Source package inconsistencies in current stable release In-Reply-To: <059.587e862dec180f2b16ae954bc957f6f5@varnish-cache.org> References: <059.587e862dec180f2b16ae954bc957f6f5@varnish-cache.org> Message-ID: <074.ab32b8e2e85eafb6174cbf294daba5a2@varnish-cache.org> #1197: Source package inconsistencies in current stable release -----------------------+--------------------- Reporter: varnish@? | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 3.0.3 Severity: major | Resolution: fixed Keywords: | -----------------------+--------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: It's in the repo now at least. Could be a missing push at some point. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 11:40:50 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 11:40:50 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <062.0c86b4c7dba126583aa5d0be16c19640@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) -------------------------------------------------+------------------------- Reporter: campisano | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: blocker | Resolution: worksforme Keywords: child died pushing vcls failed | #012CLI communication error (hdr) | -------------------------------------------------+------------------------- Changes (by martin): * status: reopened => closed * resolution: => worksforme Comment: We have added this as a future feature item, to have some parameter to control restart handling. See https://www.varnish- cache.org/trac/wiki/Future_Usability#Parametertocontrolrestartbehavior Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 11:52:57 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 11:52:57 -0000 Subject: [Varnish] #1232: vcl.load should echo something instead of a newline on success In-Reply-To: <045.a8ebf073c3dd7005ec41cb0e979ec4d4@varnish-cache.org> References: <045.a8ebf073c3dd7005ec41cb0e979ec4d4@varnish-cache.org> Message-ID: <060.1f06ed3f199066200c40cc9141e95b9a@varnish-cache.org> #1232: vcl.load should echo something instead of a newline on success -------------------------+-------------------- Reporter: derjohn | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | -------------------------+-------------------- Comment (by Tollef Fog Heen ): In [ca8dda44cf4c7a6460093c37c7b9129f60effdc6]: {{{ #!CommitTicketReference repository="" revision="ca8dda44cf4c7a6460093c37c7b9129f60effdc6" Make vcl.use slightly more chatty Output that we've switched VCLs and which one we have switched to when using vcl.use. Fixes #1232 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 11:52:58 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 11:52:58 -0000 Subject: [Varnish] #1232: vcl.load should echo something instead of a newline on success In-Reply-To: <045.a8ebf073c3dd7005ec41cb0e979ec4d4@varnish-cache.org> References: <045.a8ebf073c3dd7005ec41cb0e979ec4d4@varnish-cache.org> Message-ID: <060.addcd98ea9b65c912402afa04ac1828c@varnish-cache.org> #1232: vcl.load should echo something instead of a newline on success -------------------------+--------------------- Reporter: derjohn | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | -------------------------+--------------------- Changes (by Tollef Fog Heen ): * status: new => closed * resolution: => fixed Comment: (In [ca8dda44cf4c7a6460093c37c7b9129f60effdc6]) Make vcl.use slightly more chatty Output that we've switched VCLs and which one we have switched to when using vcl.use. Fixes #1232 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 11:57:35 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 11:57:35 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <062.dfec09d05bec9f5af352db5e19c41a04@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) -------------------------------------------------+------------------------- Reporter: campisano | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: blocker | Resolution: worksforme Keywords: child died pushing vcls failed | #012CLI communication error (hdr) | -------------------------------------------------+------------------------- Comment (by seldaek): Replying to [comment:15 martin]: > We have added this as a future feature item, to have some parameter to control restart handling. Being able to force it to retry N times is an improvement, but I still think that it should just exit at the point where it has no child process alive and can not start them anymore. Otherwise Varnish keeps running and as far as the OS and any process-based monitoring is concerned all is well while the system is actually unusable. This is quite a serious issue IMO. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 12:06:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 12:06:43 -0000 Subject: [Varnish] #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) In-Reply-To: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> References: <047.bcc0e94d7c2ef8aaaa3912631b629b9e@varnish-cache.org> Message-ID: <062.4d8a875455ff565aeff9a8a47e1e3c5b@varnish-cache.org> #1119: Varnish 3.0.2 freezed, Pushing vcls failed:#012CLI communication error (hdr) -------------------------------------------------+------------------------- Reporter: campisano | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.2 Severity: blocker | Resolution: worksforme Keywords: child died pushing vcls failed | #012CLI communication error (hdr) | -------------------------------------------------+------------------------- Comment (by martin): Replying to [comment:16 seldaek]: > Being able to force it to retry N times is an improvement, but I still think that it should just exit at the point where it has no child process alive and can not start them anymore. Otherwise Varnish keeps running and as far as the OS and any process-based monitoring is concerned all is well while the system is actually unusable. This is quite a serious issue IMO. Added to the wiki page. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 3 17:39:53 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Dec 2012 17:39:53 -0000 Subject: [Varnish] #1235: Frequent Varnish crashes - Size of Varnish cache never grows Message-ID: <048.31522a660c9c9b92f418dc9cbf9c8028@varnish-cache.org> #1235: Frequent Varnish crashes - Size of Varnish cache never grows ------------------------+---------------------- Reporter: msallen333 | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: crash | ------------------------+---------------------- *** PROBLEM DESCRIPTION *** Varnish 3.0.2-1daemon crashes and restarts at least once per week with below output in /var/log/messages. In addition, the usage of /varnish filesystem never climbs above 404G. I have already disabled "Transparent Hugepages". Has anyone else experienced this same problem, and possibly have a solution? ============================================= # /var/log/messages Dec 2 12:45:37 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:45:47 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:45:57 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) died signal=3 (core dumped) Dec 2 12:46:06 lx11 varnishd[7568]: child (9172) Started Dec 2 12:46:06 lx11 varnishd[7568]: Child (9172) said Child starts Dec 2 12:46:06 lx11 varnishd[7568]: Child (9172) said SMF.s0 mmap'ed 1589334294528 bytes of 1589334294528 # df -h | grep varnish /dev/mapper/emcvg1-varnish 2.0T 404G 1.5T 22% /varnish # ps -ef | grep arnish root 4130 1 0 Nov30 ? 00:00:10 /usr/bin/varnishlog -a -w /var/log/varnish/varnish.log -D -P /var/run/varnishlog.pid root 4137 1 0 Nov30 ? 00:07:08 /usr/bin/varnishncsa -a -w /var/log/varnish/varnishncsa.log -D -P /var/run/varnishncsa.pid root 7568 1 0 Nov30 ? 00:00:02 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,120 -u varnish -g varnish -S /etc/varnish/secret -s file,/varnish/varnish_storage.bin,98% varnish 9172 7568 13 Dec02 ? 02:48:45 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,120 -u varnish -g varnish -S /etc/varnish/secret -s file,/varnish/varnish_storage.bin,98% # cat /sys/kernel/mm/redhat_transparent_hugepage/enabled always [never] Which varnish version ? # rpm -qa | grep varnish varnish-libs-3.0.2-1.el5.x86_64 varnish-3.0.2-1.el5.x86_64 varnish-release-3.0-1.noarch Which type of CPU ? # more /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 29 model name : Intel(R) Xeon(R) CPU E7440 @ 2.40GHz stepping : 1 cpu MHz : 2400.080 cache size : 16384 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good xtopology aperfmperf pni dtes64 monitor ds_cpl vm x est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority bogomips : 4800.16 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: 32 or 64 bit mode ? 64bit how much RAM ? 128GB # more meminfo MemTotal: 132153720 kB MemFree: 662828 kB Buffers: 334308 kB Cached: 124553164 kB SwapCached: 28 kB Active: 15416940 kB Inactive: 114045600 kB Active(anon): 4406140 kB Inactive(anon): 174144 kB Active(file): 11010800 kB Inactive(file): 113871456 kB Unevictable: 5244 kB Mlocked: 5244 kB SwapTotal: 16777208 kB SwapFree: 16777080 kB Dirty: 33320 kB Writeback: 0 kB AnonPages: 4580508 kB Mapped: 68785120 kB Shmem: 1784 kB Slab: 548132 kB SReclaimable: 429880 kB SUnreclaim: 118252 kB KernelStack: 5504 kB PageTables: 158976 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 82854068 kB Committed_AS: 45740984 kB VmallocTotal: 34359738367 kB VmallocUsed: 493684 kB VmallocChunk: 34359215588 kB HardwareCorrupted: 0 kB AnonHugePages: 1718272 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 9456 kB DirectMap2M: 134205440 kB Which OS/kernel version ? # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 (Santiago) # cat /proc/version Linux version 2.6.32-220.4.2.el6.x86_64 (mockbuild at x86-003.build.bos.redhat.com) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Mon Feb 6 16:39:28 EST 2012 default VCL or do you have your own ? # cat /etc/varnish/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 = "x.y.z"; .port = "8080"; .connect_timeout = 15s; .first_byte_timeout = 120s; .between_bytes_timeout = 120s; } # # 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_fetch { set beresp.grace = 1h; if (beresp.http.content-type ~ "(text|application)") { set beresp.do_gzip = true; } } sub vcl_recv { # unset cookies since we don't want to bypass caching normally if (req.http.cookie) { unset req.http.cookie; } set req.grace = 1h; } sub vcl_deliver { if (!resp.http.Vary) { set resp.http.Vary = "Accept-Encoding"; } else if (resp.http.Vary !~ "(?i)Accept-Encoding") { set resp.http.Vary = resp.http.Vary + ",Accept-Encoding"; } } # 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 {" The page is temporarily unavailable

Chronicling America is currently unavailable

The Chronicling America website is currently offline, undergoing maintenance. We regret the inconvenience, and invite you to visit other collections available on the Library of Congress website at www.loc.gov while we are working to restore service.

"}; return (deliver); } # # sub vcl_init { # return (ok); # } # # sub vcl_fini { # return (ok); # } -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 5 11:49:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 Dec 2012 11:49:52 -0000 Subject: [Varnish] #1236: requests to same url sometimes hang Message-ID: <046.b48904a62834d0bb2f528f8d3d831dd0@varnish-cache.org> #1236: requests to same url sometimes hang ----------------------+---------------------- Reporter: reinhard | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: normal Keywords: | ----------------------+---------------------- The problem is, that if a script with some parameters takes a long time to execute it sometimes happens, that a call to the script with other parameters hangs till the first long running call is finished. we use a plain centos 6.3 with the newest varnish 3.0.3 rpms from http://repo.varnish-cache.org/redhat/varnish-3.0/el6/x86_64/. We were able to reproduce this behavior with the following setup. It doesn't happens always but on the server i tested it around 1 in 3 times so it should be fairly easy to reproduce. Attached is the script test.php. The important part is that the script sleeps 30 seconds if it is called with the parameter t=1 otherwise it returns some output i used in debugging the problem. The following steps must be done to reproduce the problem: 1.) restart varnish 2.) call the script with the parameter that the script takes a long time to finish: curl -i -H "host: test.de" 'localhost:6081/test.php?t=1&time='`date +%H_%M_%S` 3.) call the script with a parameter that finish fast. The first call always works and don't hang: curl -i -H "host: test.de" 'localhost:6081/test.php?t=2&time='`date +%H_%M_%S` 4.) call the script with a parameter that finish fast a second time immediately afterwards: curl -i -H "host: test.de" 'localhost:6081/test.php?t=3&time='`date +%H_%M_%S` If i waited to long with the third call, i wasn't able to reproduce the problem. Even if i was fast only around 1 in 3 attempts showed the problem: The call waited till the first call was finished before initiating a connection to the backend server. I have also attached the log file of varnishlog -u -O -w varnish2.log during the execution. The problem also occurs with varnish 2.1.5. Please let me know if you need further informations. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 10 02:50:07 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Dec 2012 02:50:07 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <057.42bb3c35523d5b3b2f3e2bb4fe2c339f@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+--------------------- Reporter: bevo | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------- Comment (by vickvu): The fix was applied to master and experimental-ims branches. However, it has not been merged into 3.0.1. Therefore, the defect still exists for Varnish 3.0.1, 3.0.2 and 3.0.3 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 10 10:54:26 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Dec 2012 10:54:26 -0000 Subject: [Varnish] #1230: Refine header check in bin/varnishd/mgt/mgt.h, mgt_main.c for uClibc In-Reply-To: <063.8a6a26f2ac3f22ccc5cb61cb06eda31f@varnish-cache.org> References: <063.8a6a26f2ac3f22ccc5cb61cb06eda31f@varnish-cache.org> Message-ID: <078.5621fee871d6de06b22e0b5df4a1d51d@varnish-cache.org> #1230: Refine header check in bin/varnishd/mgt/mgt.h, mgt_main.c for uClibc ----------------------+-------------------- Reporter: basile@? | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Poul-Henning Kamp ): In [881dcc3d7e2384ccf6f56de162ceebbe75d68384]: {{{ #!CommitTicketReference repository="" revision="881dcc3d7e2384ccf6f56de162ceebbe75d68384" Remove a pseudo-bogus test for pthreads in the manager process. The subsequent cleanup/separation of .h files makes this test much less important, and it's not like it is a conclusive or comprehensive test in the first place. Fixes #1230 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 10 10:54:27 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Dec 2012 10:54:27 -0000 Subject: [Varnish] #1230: Refine header check in bin/varnishd/mgt/mgt.h, mgt_main.c for uClibc In-Reply-To: <063.8a6a26f2ac3f22ccc5cb61cb06eda31f@varnish-cache.org> References: <063.8a6a26f2ac3f22ccc5cb61cb06eda31f@varnish-cache.org> Message-ID: <078.612037e6ecae003c36904e3b19f74441@varnish-cache.org> #1230: Refine header check in bin/varnishd/mgt/mgt.h, mgt_main.c for uClibc ----------------------+--------------------- Reporter: basile@? | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: (In [881dcc3d7e2384ccf6f56de162ceebbe75d68384]) Remove a pseudo-bogus test for pthreads in the manager process. The subsequent cleanup/separation of .h files makes this test much less important, and it's not like it is a conclusive or comprehensive test in the first place. Fixes #1230 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 10 11:17:06 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Dec 2012 11:17:06 -0000 Subject: [Varnish] #1235: Frequent Varnish crashes - Size of Varnish cache never grows In-Reply-To: <048.31522a660c9c9b92f418dc9cbf9c8028@varnish-cache.org> References: <048.31522a660c9c9b92f418dc9cbf9c8028@varnish-cache.org> Message-ID: <063.5e543b48a7a2ef1a4b2bf8a13f2d2565@varnish-cache.org> #1235: Frequent Varnish crashes - Size of Varnish cache never grows ------------------------+-------------------- Reporter: msallen333 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: crash | ------------------------+-------------------- Description changed by kristian: Old description: > *** PROBLEM DESCRIPTION *** > > Varnish 3.0.2-1daemon crashes and restarts at least once per week with > below output in /var/log/messages. In addition, the > usage of /varnish filesystem never climbs above 404G. > > I have already disabled "Transparent Hugepages". > > Has anyone else experienced this same problem, and possibly have a > solution? > > > ============================================= > > > # /var/log/messages > Dec 2 12:45:37 lx11 varnishd[7568]: Child (7569) not responding to CLI, > killing it. > Dec 2 12:45:47 lx11 varnishd[7568]: Child (7569) not responding to CLI, > killing it. > Dec 2 12:45:57 lx11 varnishd[7568]: Child (7569) not responding to CLI, > killing it. > Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) not responding to CLI, > killing it. > Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) not responding to CLI, > killing it. > Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) died signal=3 (core > dumped) > Dec 2 12:46:06 lx11 varnishd[7568]: child (9172) Started > Dec 2 12:46:06 lx11 varnishd[7568]: Child (9172) said Child starts > Dec 2 12:46:06 lx11 varnishd[7568]: Child (9172) said SMF.s0 mmap'ed > 1589334294528 bytes of 1589334294528 > > # df -h | grep varnish > /dev/mapper/emcvg1-varnish 2.0T 404G 1.5T 22% /varnish > > # ps -ef | grep arnish > root 4130 1 0 Nov30 ? 00:00:10 /usr/bin/varnishlog -a -w > /var/log/varnish/varnish.log -D -P /var/run/varnishlog.pid > root 4137 1 0 Nov30 ? 00:07:08 /usr/bin/varnishncsa -a > -w /var/log/varnish/varnishncsa.log -D -P /var/run/varnishncsa.pid > root 7568 1 0 Nov30 ? 00:00:02 /usr/sbin/varnishd -P > /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 > -t 120 -w 1,1000,120 -u varnish -g varnish -S /etc/varnish/secret -s > file,/varnish/varnish_storage.bin,98% > varnish 9172 7568 13 Dec02 ? 02:48:45 /usr/sbin/varnishd -P > /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 > -t 120 -w 1,1000,120 -u varnish -g varnish -S /etc/varnish/secret -s > file,/varnish/varnish_storage.bin,98% > > # cat /sys/kernel/mm/redhat_transparent_hugepage/enabled > always [never] > > > Which varnish version ? > > # rpm -qa | grep varnish > varnish-libs-3.0.2-1.el5.x86_64 > varnish-3.0.2-1.el5.x86_64 > varnish-release-3.0-1.noarch > > > Which type of CPU ? > > # more /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 29 > model name : Intel(R) Xeon(R) CPU E7440 @ 2.40GHz > stepping : 1 > cpu MHz : 2400.080 > cache size : 16384 KB > physical id : 0 > siblings : 4 > core id : 0 > cpu cores : 4 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm > constant_tsc arch_perfmon pebs bts rep_good xtopology aperfmperf pni > dtes64 monitor ds_cpl vm > x est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm dts tpr_shadow vnmi > flexpriority > bogomips : 4800.16 > clflush size : 64 > cache_alignment : 64 > address sizes : 40 bits physical, 48 bits virtual > power management: > > > 32 or 64 bit mode ? > > 64bit > > > how much RAM ? > > 128GB > > # more meminfo > MemTotal: 132153720 kB > MemFree: 662828 kB > Buffers: 334308 kB > Cached: 124553164 kB > SwapCached: 28 kB > Active: 15416940 kB > Inactive: 114045600 kB > Active(anon): 4406140 kB > Inactive(anon): 174144 kB > Active(file): 11010800 kB > Inactive(file): 113871456 kB > Unevictable: 5244 kB > Mlocked: 5244 kB > SwapTotal: 16777208 kB > SwapFree: 16777080 kB > Dirty: 33320 kB > Writeback: 0 kB > AnonPages: 4580508 kB > Mapped: 68785120 kB > Shmem: 1784 kB > Slab: 548132 kB > SReclaimable: 429880 kB > SUnreclaim: 118252 kB > KernelStack: 5504 kB > PageTables: 158976 kB > NFS_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 82854068 kB > Committed_AS: 45740984 kB > VmallocTotal: 34359738367 kB > VmallocUsed: 493684 kB > VmallocChunk: 34359215588 kB > HardwareCorrupted: 0 kB > AnonHugePages: 1718272 kB > HugePages_Total: 0 > HugePages_Free: 0 > HugePages_Rsvd: 0 > HugePages_Surp: 0 > Hugepagesize: 2048 kB > DirectMap4k: 9456 kB > DirectMap2M: 134205440 kB > > > Which OS/kernel version ? > > # cat /etc/redhat-release > Red Hat Enterprise Linux Server release 6.2 (Santiago) > # cat /proc/version > Linux version 2.6.32-220.4.2.el6.x86_64 > (mockbuild at x86-003.build.bos.redhat.com) (gcc version 4.4.6 20110731 (Red > Hat 4.4.6-3) (GCC) ) #1 SMP Mon Feb 6 16:39:28 EST 2012 > > > default VCL or do you have your own ? > > # cat /etc/varnish/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 = "x.y.z"; > .port = "8080"; > .connect_timeout = 15s; > .first_byte_timeout = 120s; > .between_bytes_timeout = 120s; > } > # > # 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_fetch { > set beresp.grace = 1h; > > if (beresp.http.content-type ~ "(text|application)") { > set beresp.do_gzip = true; > } > > } > > sub vcl_recv { > # unset cookies since we don't want to bypass caching normally > if (req.http.cookie) { > unset req.http.cookie; > } > > set req.grace = 1h; > } > > sub vcl_deliver { > if (!resp.http.Vary) { > set resp.http.Vary = "Accept-Encoding"; > } else if (resp.http.Vary !~ "(?i)Accept-Encoding") { > set resp.http.Vary = resp.http.Vary + ",Accept-Encoding"; > } > } > > # 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"> > > > The page is temporarily unavailable > > >

Chronicling America is currently unavailable

>

The Chronicling America website is currently offline, undergoing > maintenance. We regret the inconvenience, and invite you to visit other > collections available on the Library of Congress website at href="http://www.loc.gov">www.loc.gov while we are working to restore > service.

> > > "}; > return (deliver); > } > # > # sub vcl_init { > # return (ok); > # } > # > # sub vcl_fini { > # return (ok); > # } New description: *** PROBLEM DESCRIPTION *** Varnish 3.0.2-1daemon crashes and restarts at least once per week with below output in /var/log/messages. In addition, the usage of /varnish filesystem never climbs above 404G. I have already disabled "Transparent Hugepages". Has anyone else experienced this same problem, and possibly have a solution? ============================================= {{{ # /var/log/messages Dec 2 12:45:37 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:45:47 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:45:57 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) not responding to CLI, killing it. Dec 2 12:46:06 lx11 varnishd[7568]: Child (7569) died signal=3 (core dumped) Dec 2 12:46:06 lx11 varnishd[7568]: child (9172) Started Dec 2 12:46:06 lx11 varnishd[7568]: Child (9172) said Child starts Dec 2 12:46:06 lx11 varnishd[7568]: Child (9172) said SMF.s0 mmap'ed 1589334294528 bytes of 1589334294528 # df -h | grep varnish /dev/mapper/emcvg1-varnish 2.0T 404G 1.5T 22% /varnish # ps -ef | grep arnish root 4130 1 0 Nov30 ? 00:00:10 /usr/bin/varnishlog -a -w /var/log/varnish/varnish.log -D -P /var/run/varnishlog.pid root 4137 1 0 Nov30 ? 00:07:08 /usr/bin/varnishncsa -a -w /var/log/varnish/varnishncsa.log -D -P /var/run/varnishncsa.pid root 7568 1 0 Nov30 ? 00:00:02 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,120 -u varnish -g varnish -S /etc/varnish/secret -s file,/varnish/varnish_storage.bin,98% varnish 9172 7568 13 Dec02 ? 02:48:45 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 1,1000,120 -u varnish -g varnish -S /etc/varnish/secret -s file,/varnish/varnish_storage.bin,98% # cat /sys/kernel/mm/redhat_transparent_hugepage/enabled always [never] }}} Which varnish version ? {{{ # rpm -qa | grep varnish varnish-libs-3.0.2-1.el5.x86_64 varnish-3.0.2-1.el5.x86_64 varnish-release-3.0-1.noarch }}} Which type of CPU ? {{{ # more /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 29 model name : Intel(R) Xeon(R) CPU E7440 @ 2.40GHz stepping : 1 cpu MHz : 2400.080 cache size : 16384 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good xtopology aperfmperf pni dtes64 monitor ds_cpl vm x est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority bogomips : 4800.16 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: 32 or 64 bit mode ? 64bit }}} how much RAM ? 128GB {{{ # more meminfo MemTotal: 132153720 kB MemFree: 662828 kB Buffers: 334308 kB Cached: 124553164 kB SwapCached: 28 kB Active: 15416940 kB Inactive: 114045600 kB Active(anon): 4406140 kB Inactive(anon): 174144 kB Active(file): 11010800 kB Inactive(file): 113871456 kB Unevictable: 5244 kB Mlocked: 5244 kB SwapTotal: 16777208 kB SwapFree: 16777080 kB Dirty: 33320 kB Writeback: 0 kB AnonPages: 4580508 kB Mapped: 68785120 kB Shmem: 1784 kB Slab: 548132 kB SReclaimable: 429880 kB SUnreclaim: 118252 kB KernelStack: 5504 kB PageTables: 158976 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 82854068 kB Committed_AS: 45740984 kB VmallocTotal: 34359738367 kB VmallocUsed: 493684 kB VmallocChunk: 34359215588 kB HardwareCorrupted: 0 kB AnonHugePages: 1718272 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 9456 kB DirectMap2M: 134205440 kB }}} Which OS/kernel version ? {{{ # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 (Santiago) # cat /proc/version Linux version 2.6.32-220.4.2.el6.x86_64 (mockbuild at x86-003.build.bos.redhat.com) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Mon Feb 6 16:39:28 EST 2012 }}} default VCL or do you have your own ? {{{ # cat /etc/varnish/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 = "x.y.z"; .port = "8080"; .connect_timeout = 15s; .first_byte_timeout = 120s; .between_bytes_timeout = 120s; } # # 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_fetch { set beresp.grace = 1h; if (beresp.http.content-type ~ "(text|application)") { set beresp.do_gzip = true; } } sub vcl_recv { # unset cookies since we don't want to bypass caching normally if (req.http.cookie) { unset req.http.cookie; } set req.grace = 1h; } sub vcl_deliver { if (!resp.http.Vary) { set resp.http.Vary = "Accept-Encoding"; } else if (resp.http.Vary !~ "(?i)Accept-Encoding") { set resp.http.Vary = resp.http.Vary + ",Accept-Encoding"; } } # 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 {" The page is temporarily unavailable

Chronicling America is currently unavailable

The Chronicling America website is currently offline, undergoing maintenance. We regret the inconvenience, and invite you to visit other collections available on the Library of Congress website at www.loc.gov while we are working to restore service.

"}; return (deliver); } # # sub vcl_init { # return (ok); # } # # sub vcl_fini { # return (ok); # } }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 10 11:17:47 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Dec 2012 11:17:47 -0000 Subject: [Varnish] #1236: requests to same url sometimes hang In-Reply-To: <046.b48904a62834d0bb2f528f8d3d831dd0@varnish-cache.org> References: <046.b48904a62834d0bb2f528f8d3d831dd0@varnish-cache.org> Message-ID: <061.34325d9636b43e67067b788cbadbac74@varnish-cache.org> #1236: requests to same url sometimes hang ----------------------+-------------------- Reporter: reinhard | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by martin): Hi, Could you verify the minimum number of threads you have configured? This sounds like you are running with a only 1 worker thread, and you are being hit by Varnish not wanting to create new threads unless there is a real workload present needing it. Try increasing the minimum number of threads. Reagrds, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 10 12:27:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Dec 2012 12:27:21 -0000 Subject: [Varnish] #1236: requests to same url sometimes hang In-Reply-To: <046.b48904a62834d0bb2f528f8d3d831dd0@varnish-cache.org> References: <046.b48904a62834d0bb2f528f8d3d831dd0@varnish-cache.org> Message-ID: <061.d23d12ae883e78a088fc64a871141efe@varnish-cache.org> #1236: requests to same url sometimes hang ----------------------+------------------------- Reporter: reinhard | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 10 12:29:01 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Dec 2012 12:29:01 -0000 Subject: [Varnish] #1236: requests to same url sometimes hang In-Reply-To: <046.b48904a62834d0bb2f528f8d3d831dd0@varnish-cache.org> References: <046.b48904a62834d0bb2f528f8d3d831dd0@varnish-cache.org> Message-ID: <061.94a330bda686e44d1359c7c2c3342d17@varnish-cache.org> #1236: requests to same url sometimes hang ----------------------+------------------------- Reporter: reinhard | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Comment (by martin): The Varnish min/max thread settings are per thread pool, and the number of pools defaults to 2. So you were running with a total minimum of 2, which is why the problem showed only at the 3rd request. There are a number of runtime parameters that governs thread behavior in Varnish. Look in the man page and also in that section of the Varnish book. Note also that while Varnish will scale up the number of threads automatically when there is consistent thread pressure over time, that algorithm isn't designed for these low numbers and a request can be starved in that case. The default of 1 in the RPMs is just too low to make a running Varnish instance, and I believe this has been changed in recent RPMs (but your configuration files may stuck form an earlier release?) You should configure more like a minimum of 100. Varnish' threads are cheap, and if they are not ever being used they hardly take up any resources either. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 12 01:23:20 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Dec 2012 01:23:20 -0000 Subject: [Varnish] #1237: Frontend Timeout Handling Message-ID: <041.7784981ce358629cf029164dea0d9db6@varnish-cache.org> #1237: Frontend Timeout Handling -------------------+------------------------- Reporter: psa | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+------------------------- It'd be nice to be able to set a frontend timeout (I've got varnish in a low latency environment, all responses have to be done within 10 ms) and be able to point it at vcl_error() when a timeout occurs to serve up custom content. -- Ticket URL: Varnish The Varnish HTTP Accelerator From martin at varnish-software.com Mon Dec 10 12:27:06 2012 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Mon, 10 Dec 2012 13:27:06 +0100 Subject: [Varnish] #1236: requests to same url sometimes hang In-Reply-To: <50C5CE9D.9060807@metaways.de> References: <046.b48904a62834d0bb2f528f8d3d831dd0@varnish-cache.org> <061.34325d9636b43e67067b788cbadbac74@varnish-cache.org> <50C5CE9D.9060807@metaways.de> Message-ID: The Varnish min/max thread settings are per thread pool, and the number of pools defaults to 2. So you were running with a total minimum of 2, which is why the problem showed only at the 3rd request. There are a number of runtime parameters that governs thread behavior in Varnish. Look in the man page and also in that section of the Varnish book. Note also that while Varnish will scale up the number of threads automatically when there is consistent thread pressure over time, that algorithm isn't designed for these low numbers and a request can be starved in that case. The default of 1 in the RPMs is just too low to make a running Varnish instance, and I believe this has been changed in recent RPMs (but your configuration files may stuck form an earlier release?) You should configure more like a minimum of 100. Varnish' threads are cheap, and if they are not ever being used they hardly take up any resources either. Regards, Martin Blix Grydeland On Mon, Dec 10, 2012 at 12:59 PM, Reinhard Vicinus wrote: > Hi, > > yes, we are running with only 1 worker thread as minimum (-w 1,1000,120). > After changing this to 2 worker threads as minimum (-w 2,1000,120) i wasn't > able to reproduce the problem anymore. So it seams that your prediction was > right. But i have difficulties understanding why the minimum number of > threads caused that behavior, because i would expect that already the > second request would hang and not the third. > > The only explanation i have is, that after the initial request he creates > a second thread for the second request and if i'm fast enough the third > request is send as the second request hasn't finished, yet. Then varnish > don't want to create a third thread for the third request and instead > queues the third request in the queue of the first thread for execution > afterwards. Am I correct or is there another cause for this behavior? Also > if i'm right is there somewhere a description which describe how requests > are queued up? > > Thanks in advance > Reinhard > > > > On 10/12/12 12:17, Varnish wrote: > >> #1236: requests to same url sometimes hang >> ----------------------+-------**------------- >> Reporter: reinhard | Owner: >> Type: defect | Status: new >> Priority: normal | Milestone: >> Component: varnishd | Version: 3.0.3 >> Severity: normal | Resolution: >> Keywords: | >> ----------------------+-------**------------- >> >> Comment (by martin): >> >> Hi, >> >> Could you verify the minimum number of threads you have configured? This >> sounds like you are running with a only 1 worker thread, and you are >> being >> hit by Varnish not wanting to create new threads unless there is a real >> workload present needing it. Try increasing the minimum number of >> threads. >> >> Reagrds, >> Martin Blix Grydeland >> >> > > -- > Reinhard Vicinus > Metaways Infosystems GmbH > Pickhuben 2, D-20457 Hamburg > > E-Mail: r.vicinus at metaways.de > Web: http://www.metaways.de > Tel: +49 (0)40 317031-524 > Fax: +49 (0)40 317031-10 > > Metaways Infosystems GmbH - Sitz: D-22967 Tremsb?ttel > Handelsregister: Amtsgericht L?beck HRB 4508 AH > Gesch?ftsf?hrung: Hermann Thaele, L?der-H. Thaele > > -- *Martin Blix Grydeland* Senior Developer | Varnish Software AS Cell: +47 21 98 92 60 We Make Websites Fly! -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Thu Dec 13 12:11:13 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 13 Dec 2012 12:11:13 -0000 Subject: [Varnish] #1238: varnishd -p option runtime parameter splitting changes the command line as viewed by ps Message-ID: <044.f58d71ea591f1a719e0f7d90fe9b75d7@varnish-cache.org> #1238: varnishd -p option runtime parameter splitting changes the command line as viewed by ps ----------------------+------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- When varnishd parses the -p option argument on the '=' character, it replaces it with a '\0' to split it into two strings. This changes the command line as viewed by e.g. ps into a command line that is actually invalid, and can cause confusion with debugging start up scripts. {{{ $ ./varnishd -p thread_pool_min=200 -d $ ps auxww | grep varnishd /usr/local/sbin/varnishd -p thread_pool_min 200 -d }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 14 11:18:58 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Dec 2012 11:18:58 -0000 Subject: [Varnish] #1238: varnishd -p option runtime parameter splitting changes the command line as viewed by ps In-Reply-To: <044.f58d71ea591f1a719e0f7d90fe9b75d7@varnish-cache.org> References: <044.f58d71ea591f1a719e0f7d90fe9b75d7@varnish-cache.org> Message-ID: <059.84569ea2e14478f3c000046c1a7e7e49@varnish-cache.org> #1238: varnishd -p option runtime parameter splitting changes the command line as viewed by ps ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Martin Blix Grydeland ): In [801f3a62f00eea3f02023650d2f3ac144240d538]: {{{ #!CommitTicketReference repository="" revision="801f3a62f00eea3f02023650d2f3ac144240d538" Set the split character back to '=' after applying the runtime parameter to preserve the arguments as seen e.g. ps. Fixes: #1238 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 14 11:19:00 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Dec 2012 11:19:00 -0000 Subject: [Varnish] #1238: varnishd -p option runtime parameter splitting changes the command line as viewed by ps In-Reply-To: <044.f58d71ea591f1a719e0f7d90fe9b75d7@varnish-cache.org> References: <044.f58d71ea591f1a719e0f7d90fe9b75d7@varnish-cache.org> Message-ID: <059.ae3a104de18f572152a5a13845b96012@varnish-cache.org> #1238: varnishd -p option runtime parameter splitting changes the command line as viewed by ps ----------------------+--------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [801f3a62f00eea3f02023650d2f3ac144240d538]) Set the split character back to '=' after applying the runtime parameter to preserve the arguments as seen e.g. ps. Fixes: #1238 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 14 13:12:03 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Dec 2012 13:12:03 -0000 Subject: [Varnish] #1054: Child not responding to CLI, killing it In-Reply-To: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> References: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> Message-ID: <061.7b3f91dcfbd4ea8b6c1b610401e6645f@varnish-cache.org> #1054: Child not responding to CLI, killing it ---------------------------+----------------------- Reporter: scorillo | Owner: lkarsten Type: defect | Status: reopened Priority: normal | Milestone: Component: documentation | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Changes (by scorillo): * status: closed => reopened * resolution: fixed => Comment: Hello It seems that the problem persists. /var/log/messages : {{{ Dec 13 18:18:31 black-varnish varnishd[7071]: child (7072) Started Dec 13 18:18:31 black-varnish varnishd[7071]: Child (7072) said Child starts Dec 14 04:12:02 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:12:12 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:12:22 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:12:33 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:12:43 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:12:53 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:13:03 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:13:13 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:13:23 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:13:33 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:13:43 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:13:53 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:14:03 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:14:06 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:14:06 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. Dec 14 04:14:06 black-varnish varnishd[7071]: Child (7072) died signal=3 Dec 14 04:14:06 black-varnish varnishd[7071]: child (13707) Started Dec 14 04:14:06 black-varnish varnishd[7071]: Child (13707) said Child starts Dec 14 14:46:59 black-varnish varnishd[7071]: CLI telnet 127.0.0.1 42647 127.0.0.1 6082 Rd auth 0bb6df8f04bdb4a62657f4b22c5e28dc545384ea88a589258f7a3d300681531b Dec 14 14:46:59 black-varnish varnishd[7071]: CLI telnet 127.0.0.1 42647 127.0.0.1 6082 Wr 200 -----------------------------#012Varnish Cache CLI 1.0#012-----------------------------#012Linux,2.6.32-279.14.1.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit#012#012Type 'help' for command list.#012Type 'quit' to close CLI session. Dec 14 14:46:59 black-varnish varnishd[7071]: CLI telnet 127.0.0.1 42647 127.0.0.1 6082 Rd ping Dec 14 14:46:59 black-varnish varnishd[7071]: CLI telnet 127.0.0.1 42647 127.0.0.1 6082 Wr 200 PONG 1355489219 1.0 Dec 14 14:47:00 black-varnish varnishd[7071]: CLI telnet 127.0.0.1 42647 127.0.0.1 6082 Rd panic.show Dec 14 14:47:00 black-varnish varnishd[7071]: CLI telnet 127.0.0.1 42647 127.0.0.1 6082 Wr 300 Child has not panicked or panic has been cleared }}} other infos: {{{ [root at black-varnish ~]# cat /etc/redhat-release CentOS release 6.3 (Final) [root at black-varnish ~]# uname -a Linux black-varnish 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [root at black-varnish ~]# cat /sys/kernel/mm/redhat_transparent_hugepage/enabled always [never] }}} I must mention that the system is running inside a vmware virtual machine configured as in the attached image. [[Image(black-varnish.jpg)]] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 17 11:35:43 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Dec 2012 11:35:43 -0000 Subject: [Varnish] #1054: Child not responding to CLI, killing it In-Reply-To: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> References: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> Message-ID: <061.8230483ff8d1783fdcaed313382ebba6@varnish-cache.org> #1054: Child not responding to CLI, killing it ---------------------------+----------------------- Reporter: scorillo | Owner: lkarsten Type: defect | Status: reopened Priority: normal | Milestone: Component: documentation | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Comment (by martin): Hi, We believe that what you are experiencing is due to resource exhaustion on your virtual machine, and the monitoring thread in Varnish is being starved. The memory available to your Varnish instance seems on the low side, with only 2GB configured on the VM. This should be increased. If that is not possible, you could prevent Varnish scaling up to using too much memory by setting a much lower max number of threads. Maybe as low as 100-150. You could also try to disable the core dumps on the box to see if there are any hidden panic message that gets eaten due to cores taking too long time. Though I don't expect this to be the case. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 17 11:37:21 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Dec 2012 11:37:21 -0000 Subject: [Varnish] #1237: Frontend Timeout Handling In-Reply-To: <041.7784981ce358629cf029164dea0d9db6@varnish-cache.org> References: <041.7784981ce358629cf029164dea0d9db6@varnish-cache.org> Message-ID: <056.6dbd1d5e0f8b18befb514d137bf5156b@varnish-cache.org> #1237: Frontend Timeout Handling -------------------------+---------------------- Reporter: psa | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by scoof): * status: new => closed * resolution: => invalid Comment: We've been discussing this, and we're not quite sure which timeout you're looking for. Maybe this is already supported. Please have a look at the first_byte_timeout and send_timeout parameters for a start. The bug tracking system should not be used for feature requests. Please use the mailing lists to see if your use case isn't already supported, and if it isn't you can add the feature request to the Future_* pages of the wiki. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 17 11:39:05 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Dec 2012 11:39:05 -0000 Subject: [Varnish] #1235: Frequent Varnish crashes - Size of Varnish cache never grows In-Reply-To: <048.31522a660c9c9b92f418dc9cbf9c8028@varnish-cache.org> References: <048.31522a660c9c9b92f418dc9cbf9c8028@varnish-cache.org> Message-ID: <063.6b0f3a356edbed5c66f2b1b3b5bc3eed@varnish-cache.org> #1235: Frequent Varnish crashes - Size of Varnish cache never grows ------------------------+-------------------- Reporter: msallen333 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: normal | Resolution: Keywords: crash | ------------------------+-------------------- Comment (by martin): Hi, This sounds like perhaps the varnish process is being limited due to ulimit. Could you go over your ulimit settings, and also double check in /proc//limit that the limits are correct and not stopping your varnishd. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 17 15:43:15 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Dec 2012 15:43:15 -0000 Subject: [Varnish] #1054: Child not responding to CLI, killing it In-Reply-To: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> References: <046.c94a70b2cb7314de75dbde5ac039463e@varnish-cache.org> Message-ID: <061.d1ccce3efff4b9524ff44485d2587a53@varnish-cache.org> #1054: Child not responding to CLI, killing it ---------------------------+----------------------- Reporter: scorillo | Owner: lkarsten Type: defect | Status: reopened Priority: normal | Milestone: Component: documentation | Version: 3.0.2 Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Comment (by scorillo): Hi, I don't think it is a memory problem, but a problem somehow related to CPU (iowait). Take a look: {{{ /var/log/messages-20121216.gz:Dec 14 04:12:02 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:12:12 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:12:22 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:12:33 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:12:43 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:12:53 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:13:03 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:13:13 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:13:23 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:13:33 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:13:43 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:13:53 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:14:03 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:14:06 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. /var/log/messages-20121216.gz:Dec 14 04:14:06 black-varnish varnishd[7071]: Child (7072) not responding to CLI, killing it. }}} {{{ [root at black-varnish src]# sar -f /var/log/sa/sa14 Linux 2.6.32-279.14.1.el6.x86_64 (black-varnish.okazii.ro) 12/14/2012 _x86_64_ (2 CPU) 12:00:01 AM CPU %user %nice %system %iowait %steal %idle ... 04:10:01 AM all 0.22 0.00 0.11 0.62 0.00 99.05 04:20:01 AM all 0.22 0.00 0.11 27.46 0.00 72.22 04:30:01 AM all 0.21 0.00 0.10 0.45 0.00 99.24 }}} And here: {{{ Dec 16 04:10:02 black-varnish varnishd[7071]: Child (25212) not responding to CLI, killing it. Dec 16 04:10:02 black-varnish varnishd[7071]: Child (25212) not responding to CLI, killing it. }}} {{{ Linux 2.6.32-279.14.1.el6.x86_64 (black-varnish.okazii.ro) 12/16/2012 _x86_64_ (2 CPU) 12:00:01 AM CPU %user %nice %system %iowait %steal %idle ... 04:00:01 AM all 0.23 0.00 0.12 0.12 0.00 99.53 04:10:01 AM all 0.23 0.00 0.12 3.29 0.00 96.35 04:20:01 AM all 0.22 0.00 0.12 2.42 0.00 97.25 04:30:01 AM all 0.22 0.00 0.12 0.46 0.00 99.21 }}} An finally here: {{{ Dec 17 16:11:52 black-varnish varnishd[7071]: Child (14654) not responding to CLI, killing it. Dec 17 16:11:56 black-varnish varnishd[7071]: Child (14654) not responding to CLI, killing it. Dec 17 16:11:56 black-varnish varnishd[7071]: Child (14654) not responding to CLI, killing it. }}} {{{ Linux 2.6.32-279.14.1.el6.x86_64 (black-varnish.okazii.ro) 12/17/2012 _x86_64_ (2 CPU) 12:00:01 AM CPU %user %nice %system %iowait %steal %idle ... 04:10:01 PM all 0.25 0.00 0.14 0.65 0.00 98.96 04:20:01 PM all 0.64 0.00 0.21 8.00 0.00 91.15 04:30:01 PM all 0.25 0.00 0.15 0.37 0.00 99.24 }}} Thank you, Cristian -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 19 15:09:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 19 Dec 2012 15:09:16 -0000 Subject: [Varnish] #1239: Problem with cleaning up "gone" bans Message-ID: <042.4f254c324d62a995d9a1391b1db24d2f@varnish-cache.org> #1239: Problem with cleaning up "gone" bans -------------------+---------------------- Reporter: xani | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: normal Keywords: | -------------------+---------------------- Our configuration looks like this: -Varnish serves application content via ESI -application server invalidates changed content -vast majority of invalidations are done by purge, small percentage by bans -on average we got < 1 ban/s -~10GB cache about 3/4 used, ~2 mil object. After 3 days we had >170k bans in "gone" state and only few hundred active, basically none of bans were removed from list ban config is: if (req.http.X-ban-regex) { ban("obj.http.x-hash ~ ^" + req.http.host + req.http.X -ban-regex + "$"); error 200 "Banned"; } else if (req.http.X-ban-single) { ban("obj.http.x-hash == " + req.http.host + req.http.X -ban-single); error 200 "Banned"; } and then x-hash is set to right value. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 22 23:59:14 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 22 Dec 2012 23:59:14 -0000 Subject: [Varnish] #1240: Varnish keeps on restarting every 2 hours Message-ID: <045.58854c746b9cf044c0c2d19e5328a582@varnish-cache.org> #1240: Varnish keeps on restarting every 2 hours ---------------------+-------------------- Reporter: redline | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.3 | Severity: normal Keywords: | ---------------------+-------------------- Hello , My server is running on CentOS 6.3 64bits Varnish 3.0.3 keeps on restarting every 2 hours . I tried using malloc and file as storage , both causes the problem . This is the error that i see in /var/log/messages : Dec 22 15:14:52 us1 varnishd[25636]: Child (25637) died signal=15 Dec 22 15:14:52 us1 varnishd[25636]: child (8257) Started Dec 22 15:14:52 us1 varnishd[25636]: Child (8257) said Child starts Dec 22 15:14:52 us1 varnishd[25636]: Child (8257) said SMF.s0 mmap'ed 7896244224 Dec 22 17:14:04 us1 varnishd[25636]: Child (8257) died signal=15 Dec 22 17:14:04 us1 varnishd[25636]: child (27043) Started Dec 22 17:14:04 us1 varnishd[25636]: Child (27043) said Child starts Dec 22 17:14:04 us1 varnishd[25636]: Child (27043) said SMF.s0 mmap'ed 789624422 Dec 22 17:18:49 us1 varnishd[25636]: Manager got SIGINT Dec 22 17:18:51 us1 varnishd[28073]: Platform: Linux,2.6.32-220.17.1.el6.x86_64, Dec 22 17:18:51 us1 varnishd[28073]: child (28074) Started Dec 22 17:18:51 us1 varnishd[28073]: Child (28074) said Child starts Dec 22 17:18:51 us1 varnishd[28073]: Child (28074) said SMF.s0 mmap'ed 789776384 What should cause this problem ? Thank you. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Dec 23 00:00:16 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 23 Dec 2012 00:00:16 -0000 Subject: [Varnish] #1240: Varnish keeps on restarting every 2 hours In-Reply-To: <045.58854c746b9cf044c0c2d19e5328a582@varnish-cache.org> References: <045.58854c746b9cf044c0c2d19e5328a582@varnish-cache.org> Message-ID: <060.93cb30795ed30d8e86f28f7467c36428@varnish-cache.org> #1240: Varnish keeps on restarting every 2 hours ---------------------+-------------------- Reporter: redline | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ---------------------+-------------------- Comment (by redline): {{{ Dec 22 15:14:52 us1 varnishd[25636]: Child (25637) died signal=15 Dec 22 15:14:52 us1 varnishd[25636]: child (8257) Started Dec 22 15:14:52 us1 varnishd[25636]: Child (8257) said Child starts Dec 22 15:14:52 us1 varnishd[25636]: Child (8257) said SMF.s0 mmap'ed 7896244224 Dec 22 17:14:04 us1 varnishd[25636]: Child (8257) died signal=15 Dec 22 17:14:04 us1 varnishd[25636]: child (27043) Started Dec 22 17:14:04 us1 varnishd[25636]: Child (27043) said Child starts Dec 22 17:14:04 us1 varnishd[25636]: Child (27043) said SMF.s0 mmap'ed 789624422 Dec 22 17:18:49 us1 varnishd[25636]: Manager got SIGINT Dec 22 17:18:51 us1 varnishd[28073]: Platform: Linux,2.6.32-220.17.1.el6.x86_64, Dec 22 17:18:51 us1 varnishd[28073]: child (28074) Started Dec 22 17:18:51 us1 varnishd[28073]: Child (28074) said Child starts Dec 22 17:18:51 us1 varnishd[28073]: Child (28074) said SMF.s0 mmap'ed 789776384 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 29 19:41:52 2012 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 29 Dec 2012 19:41:52 -0000 Subject: [Varnish] #1241: Use Upstart on Ubuntu machines Message-ID: <046.f7286b12ea20583b4a4ae804e660c4ba@varnish-cache.org> #1241: Use Upstart on Ubuntu machines -----------------------------+------------------------- Reporter: silvinci | Type: enhancement Status: new | Priority: normal Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: normal Keywords: | -----------------------------+------------------------- Currently Varnish uses the old init.d scripts. It's time to switch to Upstart. The change should be pretty simple, although current users have to be informed about that, as they may have to alter their control scripts. -- Ticket URL: Varnish The Varnish HTTP Accelerator