From varnish-bugs at varnish-cache.org Mon Jun 3 10:28:45 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Jun 2013 10:28:45 -0000 Subject: [Varnish] #1312: Single IP in acl definition with overlapping subnet causes issue Message-ID: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> #1312: Single IP in acl definition with overlapping subnet causes issue ---------------------+-------------------- Reporter: Niels_C | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+-------------------- I have encountered a situation where a client IP is not matched against my ACL, despite an including range being listed. The client IP in question is 88.83.67.140, which is not being matched against the range "88.83.64.0"/19; On IRC, we narrowed the problem down to the fact that another, single, IP address that is also in the range is present in the ACL (88.83.67.182). When the single IP is removed, the ACL works as expected. The order of the IPs in the ACL does not appear to matter. Files being included with this bug report: default.vcl okko.vcl waoo.vcl varnishlog of the rejection occuring In other words, if I remove the single IP entry, "88.83.67.182";, from the ACL, 88.83.67.140 is matched as expected. But as soon as the 88.83.67.182 entry is included, 88.83.67.140 is no longer matched and requests are rejected. Note that I have obfuscated the backend server IPs but everything else is exactly as running config. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 3 16:54:40 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 03 Jun 2013 16:54:40 -0000 Subject: [Varnish] #1313: ban obj.size > 10MB seems broken Message-ID: <043.e540f77e678d3398737ca403a911783e@varnish-cache.org> #1313: ban obj.size > 10MB seems broken ---------------------------+------------------- Reporter: perbu | Owner: Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: ---------------------------+------------------- varnishadmin -T 127.0.0.1:4001 ban obj.size > 10MB 105 Unknown request. Type 'help' for more info. Too many parameters Banning on obj.size, which has been in the docs since the dawn of bans, seems to be broken. Is there a complete list of what you can ban on somewhere? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 4 19:43:33 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 04 Jun 2013 19:43:33 -0000 Subject: [Varnish] #1314: varnishadm and pipe Message-ID: <047.4e26d1573a50888000f823ddf62bc65c@varnish-cache.org> #1314: varnishadm and pipe -------------------------------+------------------------ Reporter: johnnyrun | Type: defect Status: new | Priority: normal Milestone: After Varnish 2.1 | Component: varnishadm Version: trunk | Severity: normal Keywords: varnishadm pipe | -------------------------------+------------------------ Hi dev! "man varnishadm" say something like: --- EXAMPLES Some ways you can use varnishadm: varnishadm -T localhost:999 -S /var/db/secret vcl.use foo echo vcl.use foo | varnishadm -T localhost:999 -S /var/db/secret echo vcl.use foo | ssh vhost varnishadm -T localhost:999 -S /var/db/secret --- unfortunately, piping to varnishadm does not work anymore. I think it is useful to do something like: cat myHugePurgeList |varnishadm -S secret But it enters in a infinite loop (varnishadm.c:279) due to probably readline problem. I made some mod resuming code pushed out from GH commit a5d5ecdea86ba6d9dcb036a78f7606c693f42190. You find by push request on github. Don't know if it is the proper way. I simply made some cut-paste from another version adding some istty() to avoid completion detection and banner output. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 7 10:56:04 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Jun 2013 10:56:04 -0000 Subject: [Varnish] #1315: Varnish doesn't respect req.ttl = 0s Message-ID: <043.51e28a4bf824b5282ca32638aed81d0a@varnish-cache.org> #1315: Varnish doesn't respect req.ttl = 0s --------------------+------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- Setting req.ttl = 0s in vcl_recv does not prevent a cached object from being served. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 7 10:59:58 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 07 Jun 2013 10:59:58 -0000 Subject: [Varnish] #1316: req.grace = 0s does not disable grace Message-ID: <043.7d816f9073ee4793116f3b2e66ed25f1@varnish-cache.org> #1316: req.grace = 0s does not disable grace --------------------+------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------- Varnish still serves stale objects with req.grace = 0s set in vcl_recv. Related: #1315 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 10 10:38:30 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Jun 2013 10:38:30 -0000 Subject: [Varnish] #1312: Single IP in acl definition with overlapping subnet causes issue In-Reply-To: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> References: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> Message-ID: <060.b349e3b9eb7d7ef9ec71c85ff361e310@varnish-cache.org> #1312: Single IP in acl definition with overlapping subnet causes issue ---------------------+-------------------- Reporter: Niels_C | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+-------------------- Changes (by phk): * owner: => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 10 10:48:30 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Jun 2013 10:48:30 -0000 Subject: [Varnish] #1311: Probe with chunked encoding results in abnormal varnishlog output In-Reply-To: <050.b0bdd4cc49a4d1d460793944567caa10@varnish-cache.org> References: <050.b0bdd4cc49a4d1d460793944567caa10@varnish-cache.org> Message-ID: <065.89432164dc7941aa218ab4d3494cb14c@varnish-cache.org> #1311: Probe with chunked encoding results in abnormal varnishlog output --------------------------+--------------------- Reporter: philipseidel | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: varnishlog | --------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 10 10:55:05 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Jun 2013 10:55:05 -0000 Subject: [Varnish] #1287: Varnish 3.0.3 - segfault in libvarnish.so. In-Reply-To: <044.f166c5ec2ec8ea0bd77090495e866ce4@varnish-cache.org> References: <044.f166c5ec2ec8ea0bd77090495e866ce4@varnish-cache.org> Message-ID: <059.4d497ee93ca6ad35d3ce4ab92e006f7f@varnish-cache.org> #1287: Varnish 3.0.3 - segfault in libvarnish.so. ------------------------------------+--------------------- Reporter: robroy | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: segfault libvarnish.so | ------------------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 10 10:56:37 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Jun 2013 10:56:37 -0000 Subject: [Varnish] #1310: varnish shouldn't allow "-" in sub names In-Reply-To: <043.09838e0e0f1907e3c74445d6767e8e71@varnish-cache.org> References: <043.09838e0e0f1907e3c74445d6767e8e71@varnish-cache.org> Message-ID: <058.a2cb4e5f78ca22290e3d5098ef14c635@varnish-cache.org> #1310: varnish shouldn't allow "-" in sub names ----------------------+-------------------- Reporter: scoof | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Changes (by phk): * owner: => phk Comment: will be fixed in VCL4 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 10 11:06:47 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Jun 2013 11:06:47 -0000 Subject: [Varnish] #1313: ban obj.size > 10MB seems broken In-Reply-To: <043.e540f77e678d3398737ca403a911783e@varnish-cache.org> References: <043.e540f77e678d3398737ca403a911783e@varnish-cache.org> Message-ID: <058.48e3d6e2814d0efbd69042e499f5e93d@varnish-cache.org> #1313: ban obj.size > 10MB seems broken ---------------------------+--------------------- Reporter: perbu | Owner: martin Type: documentation | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 11 10:19:54 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Jun 2013 10:19:54 -0000 Subject: [Varnish] #1312: Single IP in acl definition with overlapping subnet causes issue In-Reply-To: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> References: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> Message-ID: <060.1a53edce9b89d53057d9aca27c6b63c6@varnish-cache.org> #1312: Single IP in acl definition with overlapping subnet causes issue ---------------------+--------------------- Reporter: Niels_C | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [bcd514d3ffdf24ed3fd1253679deca62ce2cf1aa]: {{{ #!CommitTicketReference repository="" revision="bcd514d3ffdf24ed3fd1253679deca62ce2cf1aa" Fix two bugs in ACL compile code. Fixes #1312 See Also: CVE-2013-4090 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 11 10:32:22 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Jun 2013 10:32:22 -0000 Subject: [Varnish] #1312: Single IP in acl definition with overlapping subnet causes issue In-Reply-To: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> References: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> Message-ID: <060.9c4b6f6fc1efec11c0af7bf54356912c@varnish-cache.org> #1312: Single IP in acl definition with overlapping subnet causes issue ---------------------+--------------------- Reporter: Niels_C | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------+--------------------- Comment (by phk): Niels, I just realised that I forgot to credit you in the security advisory. I had that text in from the beginning, but lost it during the subsequent editing process. Do not doubt that your help is much appreciated: I owe you one. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 11 10:59:20 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 11 Jun 2013 10:59:20 -0000 Subject: [Varnish] #1312: Single IP in acl definition with overlapping subnet causes issue In-Reply-To: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> References: <045.cd439182e6774213762e9ddb16e1b83a@varnish-cache.org> Message-ID: <060.ab41506618fbe15e1c009178e56b1ec3@varnish-cache.org> #1312: Single IP in acl definition with overlapping subnet causes issue ---------------------+--------------------- Reporter: Niels_C | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ---------------------+--------------------- Comment (by Niels_C): Well, that made my day. Not that I accidentally found a minor vulnerability in Varnish, but that I was of assistance in its resolution. I could ask for no more. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 12 11:15:38 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Jun 2013 11:15:38 -0000 Subject: [Varnish] #1314: varnishadm and pipe In-Reply-To: <047.4e26d1573a50888000f823ddf62bc65c@varnish-cache.org> References: <047.4e26d1573a50888000f823ddf62bc65c@varnish-cache.org> Message-ID: <062.fb2e1f3f09f4c70c55071469cffbab05@varnish-cache.org> #1314: varnishadm and pipe -----------------------------+----------------------------------------- Reporter: johnnyrun | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: After Varnish 2.1 Component: varnishadm | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishadm pipe | -----------------------------+----------------------------------------- Changes (by Tollef Fog Heen ): * owner: => Tollef Fog Heen * status: new => closed * resolution: => fixed Comment: In [56a571a70f9e00545b5d5f08437fc65425c1a573]: {{{ #!CommitTicketReference repository="" revision="56a571a70f9e00545b5d5f08437fc65425c1a573" Handle input from stdin properly in varnishadm readline doesn't really handle when input comes from a file or pipe, so only use readline if stdin is a tty. Thanks to johnnyrun for a patch which was used for inspiration here. Fixes #1314 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 12 11:15:38 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Jun 2013 11:15:38 -0000 Subject: [Varnish] #1305: Varnish:time_firstbyte and others are misleading In-Reply-To: <050.29f7d4db9e158b8aa89661772a4471c8@varnish-cache.org> References: <050.29f7d4db9e158b8aa89661772a4471c8@varnish-cache.org> Message-ID: <065.95451409b30a864d2b25bb79e1900c35@varnish-cache.org> #1305: Varnish:time_firstbyte and others are misleading ---------------------------+----------------------------------------- Reporter: JonathanHuot | Owner: Tollef Fog Heen Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: trunk Severity: minor | Resolution: fixed Keywords: | ---------------------------+----------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * owner: => Tollef Fog Heen * resolution: => fixed Comment: In [7754eb3baecceadb9051dc4f768e09c6ce0ef176]: {{{ #!CommitTicketReference repository="" revision="7754eb3baecceadb9051dc4f768e09c6ce0ef176" Clear up time to first byte description in varnishncsa man page Fixes #1305 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 12 11:36:56 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 12 Jun 2013 11:36:56 -0000 Subject: [Varnish] #1298: varnishncsa startup script, Ubuntu package In-Reply-To: <046.051eaaeb8137aee21d2bdd2e304e5c66@varnish-cache.org> References: <046.051eaaeb8137aee21d2bdd2e304e5c66@varnish-cache.org> Message-ID: <061.e90eb370192a825128986f5e90dc056b@varnish-cache.org> #1298: varnishncsa startup script, Ubuntu package -----------------------+--------------------- Reporter: michaelt | Owner: tfheen Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | -----------------------+--------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in git. Will be fixed in the next release. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 13 16:40:03 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 13 Jun 2013 16:40:03 -0000 Subject: [Varnish] #1317: Varnish Crashes intermittenly Message-ID: <062.682d17d5fb5f685c64e1e491d8617a94@varnish-cache.org> #1317: Varnish Crashes intermittenly ------------------------------+-------------------- Reporter: swapnil.borade@? | Type: defect Status: new | Priority: high Milestone: Varnish 3.0 dev | Component: build Version: trunk | Severity: major Keywords: | ------------------------------+-------------------- Varnish Version /usr/sbin/varnishd -V varnishd (varnish-3.0.2 revision 55e70a4) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS Messages in Logs Jun 13 12:22:27 ipXXX varnishd[10588]: Child (22136) said Child starts Jun 13 12:22:27 ip- arnishd[10588]: Child (22136) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Jun 13 12:22:27 ip-abrtd: Package 'varnish' isn't signed with proper key Jun 13 12:22:27 ip- abrtd: 'post-create' on '/var/spool/abrt/ccpp-2013-06-13-12:22:21-22059' exited with 1 Jun 13 12:22:27 ip- abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2013-06-13-12:22:21-22059, deleting Jun 13 12:22:33 ip-kernel: possible SYN flooding on port 80. Sending cookies. Jun 13 12:27:39 ip kernel: varnishd[22187]: segfault at 0 ip 0000000000453686 sp 00007fe19cdf9df0 error 4 in varnishd[400000+72000] Jun 13 12:27:45 ip- abrt[22220]: Saved core dump of pid 22136 (/usr/sbin/varnishd) to /var/spool/abrt/ccpp-2013-06-13-12:27:39-22136 (850481152 bytes) Jun 13 12:27:45 ip-abrtd: Directory 'ccpp-2013-06-13-12:27:39-22136' creation detected Jun 13 12:27:45 ipvarnishd[10588]: Child (22136) not responding to CLI, killing it. Jun 13 12:27:45 ivarnishd[10588]: Child (22136) not responding to CLI, killing it. Jun 13 12:27:45 varnishd[10588]: Child (22136) died signal=11 (core dumped) Jun 13 12:27:45 varnishd[10588]: Child cleanup complete Jun 13 12:27:45 varnishd[10588]: child (22223) Started Jun 13 12:27:45 varnishd[10588]: Child (22223) said Child starts Jun 13 12:27:45varnishd[10588]: Child (22223) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Jun 13 12:27:45abrtd: Package 'varnish' isn't signed with proper key Jun 13 12:27:45 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2013-06-13-12:27:39-22136' exited with 1 Jun 13 12:27:45 ip-1abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2013-06-13-12:27:39-22136, deleting Jun 13 12:27:52 ip- kernel: possible SYN flooding on port 80. Sending cookies. Jun 13 12:30:01CROND[22321]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jun 13 12:32:57kernel: varnishd[22246]: segfault at 0 ip 0000000000453686 sp 00007fe1fbffedf0 error 4 in varnishd[400000+72000] Jun 13 12:33:05abrtd: Directory 'ccpp-2013-06-13-12:32:57-22223' creation detected -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 14 20:23:42 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 14 Jun 2013 20:23:42 -0000 Subject: [Varnish] #1310: varnish shouldn't allow "-" in sub names In-Reply-To: <043.09838e0e0f1907e3c74445d6767e8e71@varnish-cache.org> References: <043.09838e0e0f1907e3c74445d6767e8e71@varnish-cache.org> Message-ID: <058.00f9f5253144d397bfa39a057dec49a4@varnish-cache.org> #1310: varnish shouldn't allow "-" in sub names ----------------------+--------------------- Reporter: scoof | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [c9d1478f0cce0891896bcaf03bdf67ae5bd81594]: {{{ #!CommitTicketReference repository="" revision="c9d1478f0cce0891896bcaf03bdf67ae5bd81594" Be a bit more helpful with the VCC error messages with the names which are restricted to valid C language names. Fixes #1310 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 17 10:08:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Jun 2013 10:08:29 -0000 Subject: [Varnish] #1318: weird POST behaviour in varnish Message-ID: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> #1318: weird POST behaviour in varnish --------------------------+---------------------- Reporter: lorenzololli | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: major Keywords: | --------------------------+---------------------- Greetings, I'm experiencing a STRANGE behaviour from VARNISH during some POST. Basically, VARNISH make my BACKEND answer a generic error. I've this test configuration: backend default { .host = "10.20.30.40"; .port = "80"; .connect_timeout = 10s; .first_byte_timeout = 31s; .between_bytes_timeout = 31s; } import std; sub vcl_recv { if (req.url ~ "^/test/") { std.log("---------------+++++++++++-----------!!!!!RECV ALWAYS PASS!!!!!---------+++++++++++----------------"); return (pass); } } The meaning is try to let all the content related to urls that start with /test/ to be passed, without caching. If I try to send a POST to /test/ passing on varnish I get: $ curl --data "service=mail&email=testuser&password=testpassword" https://20.30.40.50/test/services.pl -k -v -H 'Host: www.somehost.it' -c cookie.txt -o /dev/null --user-agent "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" * About to connect() to 20.30.40.50 port 443 (#0) * Trying 20.30.40.50... * Adding handle: conn: 0x6631a0 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x6631a0) send_pipe: 1, recv_pipe: 0 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 20.30.40.50 (20.30.40.50) port 443 (#0) [... SSL ... ] * SSL certificate verify ok. > POST /test/services.pl HTTP/1.1 > User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) > Accept: */* > Host: www.somehost.it > Content-Length: 50 > Content-Type: application/x-www-form-urlencoded > } [data not shown] * upload completely sent off: 50 out of 50 bytes < HTTP/1.1 500 Internal Server Error * Server Apache/2.2.15 (CentOS) is not blacklisted < Server: Apache/2.2.15 (CentOS) < Content-Type: text/html; charset=iso-8859-1 < Content-Length: 616 < Accept-Ranges: bytes < Date: Mon, 17 Jun 2013 09:34:54 GMT < X-Varnish: 1530875689 < Age: 0 < Via: 1.1 varnish < Connection: keep-alive < { [data not shown] 100 666 100 616 100 50 1001 81 --:--:-- --:--:-- --:--:-- 1003 * Connection #0 to host 20.30.40.50 left intact This request, end with a 500 generic error, wich I can found both in varnishlog and on apachelog: 1.2.3.4 - - [17/Jun/2013:11:34:53 +0200] "POST /test/services.pl HTTP/1.1" 500 616 "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" If I change the configuration to not match POST on this URL everithing is working correctly backend default { .host = "10.20.30.40"; .port = "80"; .connect_timeout = 10s; .first_byte_timeout = 31s; .between_bytes_timeout = 31s; } import std; sub vcl_recv { if ((req.url ~ "^/test/") && (req.request != "POST")) { std.log("---------------+++++++++++-----------!!!!!RECV ALWAYS PASS!!!!!---------+++++++++++----------------"); return (pass); } if (req.request != "POST") { return (pass); } } $ curl --data "service=mail&email=testuser&password=testpassword" https://20.30.40.50/test/services.pl -k -v -H 'Host: www.somehost.it' -c cookie.txt -o /dev/null --user-agent "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" * About to connect() to 20.30.40.50 port 443 (#0) * Trying 20.30.40.50... * Adding handle: conn: 0x6631a0 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x6631a0) send_pipe: 1, recv_pipe: 0 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 20.30.40.50 (20.30.40.50) port 443 (#0) [... SSL ... ] > POST /test/services.pl HTTP/1.1 > User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) > Accept: */* > Host: www.somehost.it > Content-Length: 50 > Content-Type: application/x-www-form-urlencoded > } [data not shown] * upload completely sent off: 50 out of 50 bytes < HTTP/1.1 302 Found * Server Apache/2.2.15 (CentOS) is not blacklisted < Server: Apache/2.2.15 (CentOS) * Added cookie mail="someusercookieok" for domain somehost.it, path /, expire 0 < Set-Cookie: mail=someusercookieok; path=/; domain=.somehost.it < Location: https://mailserver.somehost.it/?username=testuser at somehost.it&password=somepassword&SessionIDMethod=yes < Content-Type: text/html; charset=iso-8859-1 < Content-Length: 392 < Accept-Ranges: bytes < Date: Mon, 17 Jun 2013 09:48:39 GMT < X-Varnish: 1724297640 < Age: 0 < Via: 1.1 varnish < Connection: keep-alive < { [data not shown] 100 442 100 392 100 50 444 56 --:--:-- --:--:-- --:--:-- 444 * Connection #0 to host 20.30.40.50 left intact This is happening always. 302 answer is fine, services.pl does authenticate then redirect to my email server. I'm using a centos 6.4 with Kernel version: varnish1 2.6.32-279.5.2.el6.x86_64 #1 SMP Fri Aug 24 01:07:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Varnish version # varnishd -V varnishd (varnish-3.0.3 revision 9e6a70f) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS Is it a bug? Best regards, Lorenzo P.s. I've posted it on forumm as well: https://www.varnish- cache.org/forum/topic/1034 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 17 10:21:54 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Jun 2013 10:21:54 -0000 Subject: [Varnish] #1317: Varnish Crashes intermittenly In-Reply-To: <062.682d17d5fb5f685c64e1e491d8617a94@varnish-cache.org> References: <062.682d17d5fb5f685c64e1e491d8617a94@varnish-cache.org> Message-ID: <077.0106589f772c3c11e494eefb38a8a046@varnish-cache.org> #1317: Varnish Crashes intermittenly ------------------------------+------------------------------ Reporter: swapnil.borade@? | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: major | Resolution: Keywords: | ------------------------------+------------------------------ Description changed by tfheen: Old description: > Varnish Version > /usr/sbin/varnishd -V > varnishd (varnish-3.0.2 revision 55e70a4) > Copyright (c) 2006 Verdens Gang AS > Copyright (c) 2006-2011 Varnish Software AS > > Messages in Logs > > Jun 13 12:22:27 ipXXX varnishd[10588]: Child (22136) said Child starts > Jun 13 12:22:27 ip- arnishd[10588]: Child (22136) said SMF.s0 mmap'ed > 1073741824 bytes of 1073741824 > Jun 13 12:22:27 ip-abrtd: Package 'varnish' isn't signed with proper key > Jun 13 12:22:27 ip- abrtd: 'post-create' on > '/var/spool/abrt/ccpp-2013-06-13-12:22:21-22059' exited with 1 > Jun 13 12:22:27 ip- abrtd: Corrupted or bad directory > /var/spool/abrt/ccpp-2013-06-13-12:22:21-22059, deleting > Jun 13 12:22:33 ip-kernel: possible SYN flooding on port 80. Sending > cookies. > Jun 13 12:27:39 ip kernel: varnishd[22187]: segfault at 0 ip > 0000000000453686 sp 00007fe19cdf9df0 error 4 in varnishd[400000+72000] > Jun 13 12:27:45 ip- abrt[22220]: Saved core dump of pid 22136 > (/usr/sbin/varnishd) to /var/spool/abrt/ccpp-2013-06-13-12:27:39-22136 > (850481152 bytes) > Jun 13 12:27:45 ip-abrtd: Directory 'ccpp-2013-06-13-12:27:39-22136' > creation detected > Jun 13 12:27:45 ipvarnishd[10588]: Child (22136) not responding to CLI, > killing it. > Jun 13 12:27:45 ivarnishd[10588]: Child (22136) not responding to CLI, > killing it. > Jun 13 12:27:45 varnishd[10588]: Child (22136) died signal=11 (core > dumped) > Jun 13 12:27:45 varnishd[10588]: Child cleanup complete > Jun 13 12:27:45 varnishd[10588]: child (22223) Started > Jun 13 12:27:45 varnishd[10588]: Child (22223) said Child starts > Jun 13 12:27:45varnishd[10588]: Child (22223) said SMF.s0 mmap'ed > 1073741824 bytes of 1073741824 > Jun 13 12:27:45abrtd: Package 'varnish' isn't signed with proper key > Jun 13 12:27:45 abrtd: 'post-create' on > '/var/spool/abrt/ccpp-2013-06-13-12:27:39-22136' exited with 1 > Jun 13 12:27:45 ip-1abrtd: Corrupted or bad directory > /var/spool/abrt/ccpp-2013-06-13-12:27:39-22136, deleting > Jun 13 12:27:52 ip- kernel: possible SYN flooding on port 80. Sending > cookies. > Jun 13 12:30:01CROND[22321]: (root) CMD (/usr/lib64/sa/sa1 1 1) > Jun 13 12:32:57kernel: varnishd[22246]: segfault at 0 ip 0000000000453686 > sp 00007fe1fbffedf0 error 4 in varnishd[400000+72000] > Jun 13 12:33:05abrtd: Directory 'ccpp-2013-06-13-12:32:57-22223' creation > detected New description: Varnish Version {{{ /usr/sbin/varnishd -V varnishd (varnish-3.0.2 revision 55e70a4) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS }}} Messages in Logs {{{ Jun 13 12:22:27 ipXXX varnishd[10588]: Child (22136) said Child starts Jun 13 12:22:27 ip- arnishd[10588]: Child (22136) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Jun 13 12:22:27 ip-abrtd: Package 'varnish' isn't signed with proper key Jun 13 12:22:27 ip- abrtd: 'post-create' on '/var/spool/abrt/ccpp-2013-06-13-12:22:21-22059' exited with 1 Jun 13 12:22:27 ip- abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2013-06-13-12:22:21-22059, deleting Jun 13 12:22:33 ip-kernel: possible SYN flooding on port 80. Sending cookies. Jun 13 12:27:39 ip kernel: varnishd[22187]: segfault at 0 ip 0000000000453686 sp 00007fe19cdf9df0 error 4 in varnishd[400000+72000] Jun 13 12:27:45 ip- abrt[22220]: Saved core dump of pid 22136 (/usr/sbin/varnishd) to /var/spool/abrt/ccpp-2013-06-13-12:27:39-22136 (850481152 bytes) Jun 13 12:27:45 ip-abrtd: Directory 'ccpp-2013-06-13-12:27:39-22136' creation detected Jun 13 12:27:45 ipvarnishd[10588]: Child (22136) not responding to CLI, killing it. Jun 13 12:27:45 ivarnishd[10588]: Child (22136) not responding to CLI, killing it. Jun 13 12:27:45 varnishd[10588]: Child (22136) died signal=11 (core dumped) Jun 13 12:27:45 varnishd[10588]: Child cleanup complete Jun 13 12:27:45 varnishd[10588]: child (22223) Started Jun 13 12:27:45 varnishd[10588]: Child (22223) said Child starts Jun 13 12:27:45varnishd[10588]: Child (22223) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Jun 13 12:27:45abrtd: Package 'varnish' isn't signed with proper key Jun 13 12:27:45 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2013-06-13-12:27:39-22136' exited with 1 Jun 13 12:27:45 ip-1abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2013-06-13-12:27:39-22136, deleting Jun 13 12:27:52 ip- kernel: possible SYN flooding on port 80. Sending cookies. Jun 13 12:30:01CROND[22321]: (root) CMD (/usr/lib64/sa/sa1 1 1) Jun 13 12:32:57kernel: varnishd[22246]: segfault at 0 ip 0000000000453686 sp 00007fe1fbffedf0 error 4 in varnishd[400000+72000] Jun 13 12:33:05abrtd: Directory 'ccpp-2013-06-13-12:32:57-22223' creation detected }}} -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 17 10:30:06 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Jun 2013 10:30:06 -0000 Subject: [Varnish] #1317: Varnish Crashes intermittenly In-Reply-To: <062.682d17d5fb5f685c64e1e491d8617a94@varnish-cache.org> References: <062.682d17d5fb5f685c64e1e491d8617a94@varnish-cache.org> Message-ID: <077.d77dfe557a49f091c993c86a923fc82b@varnish-cache.org> #1317: Varnish Crashes intermittenly ------------------------------+------------------------------ Reporter: swapnil.borade@? | Owner: Type: defect | Status: new Priority: high | Milestone: Varnish 3.0 dev Component: build | Version: trunk Severity: major | Resolution: Keywords: | ------------------------------+------------------------------ Comment (by daghf): Could you please also include a backtrace from the core dump that was collected? For instructions, look here: https://www.varnish- cache.org/trac/wiki/DebuggingVarnish#Gettingusefulcoredumps -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 17 10:38:05 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Jun 2013 10:38:05 -0000 Subject: [Varnish] #1318: weird POST behaviour in varnish In-Reply-To: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> References: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> Message-ID: <065.922de3d13873d3e3476282c5fe13abdd@varnish-cache.org> #1318: weird POST behaviour in varnish --------------------------+-------------------- Reporter: lorenzololli | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: Keywords: | --------------------------+-------------------- Comment (by daghf): Hard to say much at all as to whether varnish is at fault here without varnishlog output. Can you please include varnishlog output for the complete request? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 17 12:13:02 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Jun 2013 12:13:02 -0000 Subject: [Varnish] #1318: weird POST behaviour in varnish In-Reply-To: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> References: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> Message-ID: <065.1d3c8d234945671e7f55963bdca05f03@varnish-cache.org> #1318: weird POST behaviour in varnish --------------------------+-------------------- Reporter: lorenzololli | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: Keywords: | --------------------------+-------------------- Comment (by lorenzololli): I'm sorry, I was pretty sure that I've added it. Log with error: 12 BackendOpen b default 1.2.3.4 59079 2.3.4.5 80 12 TxRequest b POST 12 TxURL b /test/services.pl 12 TxProtocol b HTTP/1.1 12 TxHeader b User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 12 TxHeader b Accept: */* 12 TxHeader b Host: www.somehost.it 12 TxHeader b Content-Length: 50 12 TxHeader b Content-Type: application/x-www-form-urlencoded 12 TxHeader b X-Varnish: 177583886 12 RxProtocol b HTTP/1.1 12 RxStatus b 500 12 RxResponse b Internal Server Error 12 RxHeader b Date: Mon, 17 Jun 2013 11:30:19 GMT 12 RxHeader b Server: Apache/2.2.15 (CentOS) 12 RxHeader b Content-Length: 616 12 RxHeader b Connection: close 12 RxHeader b Content-Type: text/html; charset=iso-8859-1 12 Fetch_Body b 4(length) cls 0 mklen 1 12 Length b 616 12 BackendClose b default 11 SessionOpen c 20.30.40.50 32439 :80 11 ReqStart c 20.30.40.50 32439 177583886 11 RxRequest c POST 11 RxURL c /test/services.pl 11 RxProtocol c HTTP/1.1 11 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 11 RxHeader c Accept: */* 11 RxHeader c Host: www.somehost.it 11 RxHeader c Content-Length: 50 11 RxHeader c Content-Type: application/x-www-form-urlencoded 11 VCL_call c recv 11 VCL_Log c ---------------+++++++++++-----------!!!!!RECV ALWAYS PASS!!!!!---------+++++++++++---------------- 11 VCL_return c pass 11 VCL_call c hash 11 Hash c /test/services.pl 11 Hash c www.somehost.it 11 VCL_return c hash 11 VCL_call c pass pass 11 Backend c 12 default default 11 TTL c 177583886 RFC -1 -1 -1 1371468620 0 1371468619 0 0 11 VCL_call c fetch 11 TTL c 177583886 VCL 121 -1 -1 1371468619 -1 11 VCL_return c hit_for_pass 11 ObjProtocol c HTTP/1.1 11 ObjResponse c Internal Server Error 11 ObjHeader c Date: Mon, 17 Jun 2013 11:30:19 GMT 11 ObjHeader c Server: Apache/2.2.15 (CentOS) 11 ObjHeader c Content-Length: 616 11 ObjHeader c Content-Type: text/html; charset=iso-8859-1 11 VCL_call c deliver deliver 11 TxProtocol c HTTP/1.1 11 TxStatus c 500 11 TxResponse c Internal Server Error 11 TxHeader c Server: Apache/2.2.15 (CentOS) 11 TxHeader c Content-Type: text/html; charset=iso-8859-1 11 TxHeader c Content-Length: 616 11 TxHeader c Accept-Ranges: bytes 11 TxHeader c Date: Mon, 17 Jun 2013 11:30:20 GMT 11 TxHeader c X-Varnish: 177583886 11 TxHeader c Age: 0 11 TxHeader c Via: 1.1 varnish 11 TxHeader c Connection: keep-alive 11 Length c 616 11 ReqEnd c 177583886 1371468619.267874002 1371468620.103220463 0.000317812 0.835056543 0.000289917 11 SessionClose c EOF 11 StatSess c 20.30.40.50 32439 1 1 1 0 1 1 267 616 Log without error: 12 BackendOpen b default 1.2.3.4 59076 2.3.4.5 80 12 TxRequest b POST 12 TxURL b /test/services.pl 12 TxProtocol b HTTP/1.1 12 TxHeader b User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 12 TxHeader b Accept: */* 12 TxHeader b Host: www.somehost.it 12 TxHeader b Content-Length: 50 12 TxHeader b Content-Type: application/x-www-form-urlencoded 12 TxHeader b X-Forwarded-For: 20.30.40.50 12 TxHeader b X-Varnish: 1724297818 12 RxProtocol b HTTP/1.1 12 RxStatus b 302 12 RxResponse b Found 12 RxHeader b Date: Mon, 17 Jun 2013 11:25:41 GMT 12 RxHeader b Server: Apache/2.2.15 (CentOS) 12 RxHeader b Set-Cookie: mail=someuser; path=/; domain=.somehost.it 12 RxHeader b Location: https://mail.somehost.it/?username=someuser at somehost.it&password=somepas... 12 RxHeader b Content-Length: 392 12 RxHeader b Connection: close 12 RxHeader b Content-Type: text/html; charset=iso-8859-1 12 Fetch_Body b 4(length) cls 0 mklen 1 12 Length b 392 12 BackendClose b default 11 SessionOpen c 20.30.40.50 40713 :80 11 ReqStart c 20.30.40.50 40713 1724297818 11 RxRequest c POST 11 RxURL c /test/services.pl 11 RxProtocol c HTTP/1.1 11 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 11 RxHeader c Accept: */* 11 RxHeader c Host: www.somehost.it 11 RxHeader c Content-Length: 50 11 RxHeader c Content-Type: application/x-www-form-urlencoded 11 VCL_call c recv pass 11 VCL_call c hash 11 Hash c /test/services.pl 11 Hash c www.somehost.it 11 VCL_return c hash 11 VCL_call c pass pass 11 Backend c 12 default default 11 TTL c 1724297818 RFC 120 -1 -1 1371468342 0 1371468341 0 0 11 VCL_call c fetch 11 TTL c 1724297818 VCL 121 -1 -1 1371468341 -1 11 VCL_return c hit_for_pass 11 ObjProtocol c HTTP/1.1 11 ObjResponse c Found 11 ObjHeader c Date: Mon, 17 Jun 2013 11:25:41 GMT 11 ObjHeader c Server: Apache/2.2.15 (CentOS) 11 ObjHeader c Set-Cookie: mail=someuser; path=/; domain=.somehost.it 11 ObjHeader c Location: https:/mail.somehost.it/?username=someuser at somehost.it&password=somepass... 11 ObjHeader c Content-Length: 392 11 ObjHeader c Content-Type: text/html; charset=iso-8859-1 11 VCL_call c deliver deliver 11 TxProtocol c HTTP/1.1 11 TxStatus c 302 11 TxResponse c Found 11 TxHeader c Server: Apache/2.2.15 (CentOS) 11 TxHeader c Set-Cookie: mail=someuser; path=/; domain=.somehost.it 11 TxHeader c Location: https://mail.somehost.it/?username=someuser at somehost.it&password=somepas... 11 TxHeader c Content-Type: text/html; charset=iso-8859-1 11 TxHeader c Content-Length: 392 11 TxHeader c Accept-Ranges: bytes 11 TxHeader c Date: Mon, 17 Jun 2013 11:25:42 GMT 11 TxHeader c X-Varnish: 1724297818 11 TxHeader c Age: 0 11 TxHeader c Via: 1.1 varnish 11 TxHeader c Connection: keep-alive 11 Length c 392 11 ReqEnd c 1724297818 1371468341.410154343 1371468342.261449814 0.000349760 0.851178408 0.000117064 11 SessionClose c EOF 11 StatSess c 20.30.40.50 40713 1 1 1 0 1 1 473 392 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 17 13:11:47 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Jun 2013 13:11:47 -0000 Subject: [Varnish] #1318: weird POST behaviour in varnish In-Reply-To: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> References: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> Message-ID: <065.19f5d19ce5baefdbc923d1c78431531a@varnish-cache.org> #1318: weird POST behaviour in varnish --------------------------+-------------------- Reporter: lorenzololli | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: Keywords: | --------------------------+-------------------- Comment (by daghf): For the failing request there is an explicit return (pass) in vcl_recv that prevents the default vcl_recv handling from being executed. Does your backend application depend on the x-forwarded-for header, perhaps? I can't see anything here that indicates that Varnish is at fault. Try varnish-misc or the forums for further help. Closing this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 17 13:11:54 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Jun 2013 13:11:54 -0000 Subject: [Varnish] #1318: weird POST behaviour in varnish In-Reply-To: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> References: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> Message-ID: <065.b19faa7ae0b21d2330f101f5f2d6d77a@varnish-cache.org> #1318: weird POST behaviour in varnish --------------------------+---------------------- Reporter: lorenzololli | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: invalid Keywords: | --------------------------+---------------------- Changes (by daghf): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 17 13:19:04 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 17 Jun 2013 13:19:04 -0000 Subject: [Varnish] #1318: weird POST behaviour in varnish In-Reply-To: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> References: <050.77f4b6084fe4ae3c49a03e70d84dcf5c@varnish-cache.org> Message-ID: <065.932f820a2a255247dbcbe72451b1973a@varnish-cache.org> #1318: weird POST behaviour in varnish --------------------------+---------------------- Reporter: lorenzololli | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: invalid Keywords: | --------------------------+---------------------- Comment (by lorenzololli): Replying to [comment:4 daghf]: No, the backend application does not depend on x-forwarded-for. In the case described above, I had the same request, same client, same backend, and network topology on both request, all that changes, is the varnish configuration. Since the problem IS always reproducible, maybe you can check it? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 18 18:50:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 18 Jun 2013 18:50:29 -0000 Subject: [Varnish] #1319: Daemon Package should depend on exact library version Message-ID: <041.3d5142236d5cf8faf1c871b7383e5964@varnish-cache.org> #1319: Daemon Package should depend on exact library version -------------------+----------------------- Reporter: tex | Type: defect Status: new | Priority: normal Milestone: | Component: packaging Version: 3.0.4 | Severity: normal Keywords: | -------------------+----------------------- The varnish Debian/Ubuntu package should depend on the exact version of libvarnishapi1. Otherwise a version mismatch may cause certain tools - like varnishstat - to report incorrect output. This can be achieved be changing the Depends line of the package control file (debian/control) to include the exact binary version like this: Depends: ..., libvarnishapi1 (= ${binary:Version}), ... Of course this will only work when built from the same source package. Otherwise the versioned dependency must be specified manually. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 21 13:00:53 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Jun 2013 13:00:53 -0000 Subject: [Varnish] #1320: Varnish returns a 503 when being given a 302 by the webapp Message-ID: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> #1320: Varnish returns a 503 when being given a 302 by the webapp -------------------+-------------------- Reporter: Wilb | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.3 | Severity: normal Keywords: | -------------------+-------------------- This morning I've been looking to put Varnish in front of our Liferay cluster, but was repeatedly seeing Varnish serve up 503 errors. After spending a bit of time scratching my head over I came to realise that it was happening whenever Liferay served up a 302 redirect. This led me to the following unanswered thread on the mailing list: http://www.gossamer-threads.com/lists/varnish/misc/25910 I was running Varnish as packaged with Debian Wheezy, which indeed is 3.0.3. My first attempt at a fix was to upgrade to your package of 3.0.4, but this suffered the same problem. Dropping back down to the Squeeze packaged 3.0.2. from your repo fixes the issue and all is behaving well. When looking at varnishlog while the requests come in I see the very same "TestGunzip error at the very end" error whether running 3.0.3 or 3.0.4. The setup I was using for this was Varnish -> Apache 2.2 -> Tomcat and it could be reproduced by hitting /c/portal/login. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 21 13:56:43 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Jun 2013 13:56:43 -0000 Subject: [Varnish] #1320: Varnish returns a 503 when being given a 302 by the webapp In-Reply-To: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> References: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> Message-ID: <057.f7866de5253d19bbfea45964a93d6654@varnish-cache.org> #1320: Varnish returns a 503 when being given a 302 by the webapp --------------------+-------------------- Reporter: Wilb | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by daghf): Hi Can you please include complete varnishlog output for the request where you see this issue? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 21 20:55:47 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Jun 2013 20:55:47 -0000 Subject: [Varnish] #1320: Varnish returns a 503 when being given a 302 by the webapp In-Reply-To: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> References: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> Message-ID: <057.57735de9e8ad3b8fa25182a5e563d913@varnish-cache.org> #1320: Varnish returns a 503 when being given a 302 by the webapp --------------------+-------------------- Reporter: Wilb | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by Wilb): Yep - I've sanitised the hostname and IPs, not that it matters much. {{{ 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1371847442 1.0 0 CLI - Rd ping 0 CLI - Wr 200 19 PONG 1371847445 1.0 12 TxRequest - GET 12 TxURL - /c/portal/login 12 TxProtocol - HTTP/1.1 12 TxHeader - Host: www.liferay.site 12 TxHeader - User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 12 TxHeader - Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 12 TxHeader - Accept-Language: en-gb,en;q=0.5 12 TxHeader - Cookie: __utma=41825786.591786166.1371051835.1371051835.1371822508.2; __utmz=41825786.1371051835.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=152615083.1629408066.1371661522.1371828953.1371847424.8; __utmz=152615083.1371720885.5.2.utmcsr=vouc 12 TxHeader - X-Forwarded-Proto: https 12 TxHeader - X-SSL-cipher: DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 12 TxHeader - X-Forwarded-For: 172.30.1.162 12 TxHeader - Accept-Encoding: gzip 12 TxHeader - X-Varnish: 931012026 12 RxProtocol - HTTP/1.1 12 RxStatus - 302 12 RxResponse - Found 12 RxHeader - Date: Fri, 21 Jun 2013 20:44:07 GMT 12 RxHeader - Content-Encoding: gzip 12 RxHeader - Set-Cookie: GUEST_LANGUAGE_ID=en_GB; Expires=Sat, 21-Jun-2014 20:44:07 GMT; Path=/; Secure 12 RxHeader - Location: https://www.liferay.site/home?p_p_id=58&p_p_lifecycle=0&p_p_state=maximized&p_p_mode=view&saveLastPath=0&_58_struts_action=%2Flogin%2Flogin 12 RxHeader - Content-Type: text/html;charset=UTF-8 12 RxHeader - Content-Length: 0 12 Fetch_Body - 4(length) cls -1 mklen 1 12 BackendClose - default 10 SessionOpen c 127.0.0.1 33365 127.0.0.1:80 10 ReqStart c 127.0.0.1 33365 931012026 10 RxRequest c GET 10 RxURL c /c/portal/login 10 RxProtocol c HTTP/1.1 10 RxHeader c Host: www.liferay.site 10 RxHeader c User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 10 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 10 RxHeader c Accept-Language: en-gb,en;q=0.5 10 RxHeader c Accept-Encoding: gzip, deflate 10 RxHeader c Cookie: __utma=41825786.591786166.1371051835.1371051835.1371822508.2; __utmz=41825786.1371051835.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=152615083.1629408066.1371661522.1371828953.1371847424.8; __utmz=152615083.1371720885.5.2.utmcsr=vouc 10 RxHeader c Connection: keep-alive 10 RxHeader c X-Forwarded-Proto: https 10 RxHeader c X-SSL-cipher: DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 10 RxHeader c X-Forwarded-For: IP.WAS.HERE 10 VCL_call c recv pass 10 VCL_call c hash 10 Hash c /c/portal/login 10 Hash c www.liferay.site 10 VCL_return c hash 10 VCL_call c pass pass 10 Backend c 12 default default 10 TTL c 931012026 RFC 120 -1 -1 1371847447 0 1371847447 0 0 10 VCL_call c fetch 10 TTL c 931012026 VCL 120 -1 -1 1371847447 -0 10 VCL_return c hit_for_pass 10 ObjProtocol c HTTP/1.1 10 ObjResponse c Found 10 ObjHeader c Date: Fri, 21 Jun 2013 20:44:07 GMT 10 ObjHeader c Content-Encoding: gzip 10 ObjHeader c Set-Cookie: GUEST_LANGUAGE_ID=en_GB; Expires=Sat, 21-Jun-2014 20:44:07 GMT; Path=/; Secure 10 ObjHeader c Location: https://www.liferay.site/home?p_p_id=58&p_p_lifecycle=0&p_p_state=maximized&p_p_mode=view&saveLastPath=0&_58_struts_action=%2Flogin%2Flogin 10 ObjHeader c Content-Type: text/html;charset=UTF-8 10 ObjHeader c Content-Length: 0 10 Gzip c u F - 0 0 0 0 0 10 FetchError c TestGunzip error at the very end 10 VCL_call c error deliver 10 VCL_call c deliver deliver 10 TxProtocol c HTTP/1.1 10 TxStatus c 503 10 TxResponse c Service Unavailable 10 TxHeade }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 21 21:11:24 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 21 Jun 2013 21:11:24 -0000 Subject: [Varnish] #1320: Varnish returns a 503 when being given a 302 by the webapp In-Reply-To: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> References: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> Message-ID: <057.9c077e52c6c837173e18665f3c502f61@varnish-cache.org> #1320: Varnish returns a 503 when being given a 302 by the webapp --------------------+-------------------- Reporter: Wilb | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by Wilb): This log was taken after reinstalling 3.0.4 from your repo, which looks to match the sort of output I was getting when using 3.0.3 from the Wheezy repo. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Jun 23 14:01:58 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 23 Jun 2013 14:01:58 -0000 Subject: [Varnish] #1321: Varnish 3.0.4 sends broken Content-length header Message-ID: <045.09cec001e41a112acafbb9a7ec6d11f4@varnish-cache.org> #1321: Varnish 3.0.4 sends broken Content-length header ---------------------+--------------------- Reporter: crashev | Type: defect Status: new | Priority: highest Milestone: | Component: build Version: 3.0.4 | Severity: normal Keywords: | ---------------------+--------------------- I just upgraded varnish from 3.0.3 to 3.0.4 and it went crazy. For some reason varnish 3.0.4 sends broke Content-length hedaer, which is empty to backend - in case of using Nginx, Nginx will return error 400 Bad Request for it and will report "client sent invalid "Content-Length" header" When debugging with varnishlog -b -m .... I saw that it happends always for the second time - when BackendReuse was in play, and the header looked like: 26 TxHeader b Content-Length: It is a major flow which crashes apps. Sorry don't have more logs, but I found it on production and had to as fast as possible have to switch back to varnish 3.0.3 in order to keep business running. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Jun 25 22:25:16 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 25 Jun 2013 22:25:16 -0000 Subject: [Varnish] #1320: Varnish returns a 503 when being given a 302 by the webapp In-Reply-To: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> References: <042.e26368a7c676e3ed22ccad2cf3d7d4cd@varnish-cache.org> Message-ID: <057.a2aef984146954bea1dc01a076c41377@varnish-cache.org> #1320: Varnish returns a 503 when being given a 302 by the webapp --------------------+-------------------- Reporter: Wilb | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.3 Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by syssi): I hit the same issue (TYPO3, Apache, Varnish). It is reproducible by: If you remove "Content-Encoding: gzip" varnish does not hit "Gunzip+ESI Failed at the very end " anymore. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 26 12:08:15 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 26 Jun 2013 12:08:15 -0000 Subject: [Varnish] #1321: Varnish 3.0.4 sends broken Content-length header In-Reply-To: <045.09cec001e41a112acafbb9a7ec6d11f4@varnish-cache.org> References: <045.09cec001e41a112acafbb9a7ec6d11f4@varnish-cache.org> Message-ID: <060.be60a43aa1d56fcf5e8b7df5dbb2d84f@varnish-cache.org> #1321: Varnish 3.0.4 sends broken Content-length header ---------------------+-------------------- Reporter: crashev | Owner: Type: defect | Status: new Priority: highest | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: Keywords: | ---------------------+-------------------- Comment (by daghf): The reporter sent me his VCL, and the problem stems from the fact that the semantics for assignments from unset headers changed slightly in 3.0.4. The change introduced in 3.0.4 is for assignment statements like {{{ set req.http.foo = req.http.bar; }}} where the 'bar' header doesn't exist. For 3.0.3 the result would be that it left req.http.foo unset, whereas in 3.0.4 the result is that req.http.foo is set to an empty string. If you need the 3.0.3 behavior in 3.0.4 this can be done by rewriting your VCL to {{{ if (req.http.bar) { set req.http.foo = req.http.bar; } }}} Related: #1218 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 26 12:09:21 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 26 Jun 2013 12:09:21 -0000 Subject: [Varnish] #1321: Varnish 3.0.4 sends broken Content-length header In-Reply-To: <045.09cec001e41a112acafbb9a7ec6d11f4@varnish-cache.org> References: <045.09cec001e41a112acafbb9a7ec6d11f4@varnish-cache.org> Message-ID: <060.aa4a6ab57bf971276ad996415c05cd3a@varnish-cache.org> #1321: Varnish 3.0.4 sends broken Content-length header ---------------------+---------------------- Reporter: crashev | Owner: Type: defect | Status: closed Priority: highest | Milestone: Component: build | Version: 3.0.4 Severity: normal | Resolution: invalid Keywords: | ---------------------+---------------------- Changes (by daghf): * status: new => closed * resolution: => invalid -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Jun 28 14:15:38 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 28 Jun 2013 14:15:38 -0000 Subject: [Varnish] #1322: varnishd master segfault when parsing <=varnish-3 director vcl Message-ID: <040.9413d6c1cb10608299178d8543e1f30a@varnish-cache.org> #1322: varnishd master segfault when parsing <=varnish-3 director vcl ---------------------------+---------------------- Reporter: jw | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: vcl, director | ---------------------------+---------------------- varnish master fails to parse an old style vcl if it contains any director (doesn't really matter which or how it is configured). {{{ $ ./sbin/varnishd -d -f ./etc/varnish/default.vcl -C Message from VCC-compiler: Not running as root, no priv-sep Running VCC-compiler failed, signal 11, core dumped $ ./sbin/varnishd -V varnishd (varnish-trunk revision 51ea9e6) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS }}} {{{ backend default { .host = "127.0.0.1"; .port = "80"; } director b2 random { .retries = 5; { .backend = { .host = "192.168.100.11"; .port = "8000"; } .weight = 3; } } sub vcl_recv { set req.backend = b2; } }}} {{{ #0 vcc_iline (tail=0, ll=, t=0x0) at vcc_token.c:71 #1 vcc_ErrWhere (tl=0xa45f50, t=0x0) at vcc_token.c:238 #2 0x00007f3eb59b97a7 in vcc_Parse (tl=tl at entry=0xa45f50) at vcc_parse.c:326 #3 0x00007f3eb59b4b76 in vcc_CompileSource (sp=, sb=0xa45f50, tl0=) at vcc_compile.c:666 #4 VCC_Compile (tl=, sb=sb at entry=0xa45220, b=) at vcc_compile.c:742 #5 0x000000000044d5df in run_vcc (priv=0x7fffb7a99dc0) at mgt/mgt_vcc.c:148 #6 0x00007f3eb5fd8b7c in VSUB_run (sb=sb at entry=0xa451e0, func=func at entry=0x44d500 , priv=priv at entry=0x7fffb7a99dc0, name=name at entry=0x46f054 "VCC- compiler", maxlines=maxlines at entry=-1) at vsub.c:103 #7 0x000000000044d882 in mgt_run_cc (C_flag=, sb=0xa451e0, vcl=0xa45340 "backend default {\n .host = \"127.0.0.1\";\n .port = \"80\";\n}\n\ndirector b2 random {\n\t.retries = 5;\n\t{\n\t\t.backend = {\n\t\t.host = \"192.168.100.11\";\n \t\t.port = \"8000\";\n\t\t}\n\t.weight = 3;\n\t}"...) at mgt/mgt_vcc.c:256 #8 mgt_VccCompile (sb=0x7fffb7a99e18, b=0xa45340 "backend default {\n .host = \"127.0.0.1\";\n .port = \"80\";\n}\n\ndirector b2 random {\n\t.retries = 5;\n\t{\n\t\t.backend = {\n\t\t.host = \"192.168.100.11\";\n \t\t.port = \"8000\";\n\t\t}\n\t.weight = 3;\n\t}"..., C_flag=1) at mgt/mgt_vcc.c:324 #9 0x000000000044df06 in mgt_vcc_default (b_arg=b_arg at entry=0x0, f_arg=f_arg at entry=0x7fffb7a9cb25 "./etc/varnish/default.vcl", vcl=vcl at entry=0xa45340 "backend default {\n .host = \"127.0.0.1\";\n .port = \"80\";\n}\n\ndirector b2 random {\n\t.retries = 5;\n\t{\n\t\t.backend = {\n\t\t.host = \"192.168.100.11\";\n \t\t.port = \"8000\";\n\t\t}\n\t.weight = 3;\n\t}"..., C_flag=C_flag at entry=1) at mgt/mgt_vcc.c:413 #10 0x000000000040dde4 in main (argc=, argv=) at mgt/mgt_main.c:605 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From yanzhenli83 at gmail.com Mon Jun 3 06:25:57 2013 From: yanzhenli83 at gmail.com (zhenli yan) Date: Mon, 03 Jun 2013 06:25:57 -0000 Subject: Crash: "Assert error in exp_timer(), cache_expire.c line 360" Message-ID: The varnish version is 3.0.3-plus. Assert error in exp_timer(), cache_expire.c line 360: Condition((oc)->magic == 0x4d301302) not true. thread = (cache-timeout) ident = Linux,2.6.32.59-0.7-xen,x86_64,-spersistent,-smalloc,-hclassic,epoll Backtrace: 0x431fa3: pan_ic+d3 0x4246d6: exp_timer+86 0x434709: wrk_bgthread+a9 0x7f4e341886a6: _end+7f4e33b0732e 0x7f4e33ef7f7d: _end+7f4e33876c05 -------------- next part -------------- An HTML attachment was scrubbed... URL: From varnish-bugs at varnish-cache.org Wed Jun 5 13:06:44 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 Jun 2013 13:06:44 -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.09f008b18cd0d5a5c3894ef02549276a@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 andrii.grytsenko): Hi, The problem is still exist, but now even worse, because every now and then child process is killed by parent and has not been re-spawned back. {{{ May 26 05:01:49 proxy-001 varnishd[20918]: child (19143) Started May 26 05:01:49 proxy-001 varnishd[20918]: Child (19143) said Child starts May 26 05:02:17 proxy-001 varnishd[20918]: Child (19143) not responding to CLI, killing it. May 26 05:02:20 proxy-001 varnishd[20918]: Child (19143) not responding to CLI, killing it. May 26 05:02:20 proxy-001 varnishd[20918]: Child (19143) died signal=3 May 26 05:02:20 proxy-001 varnishd[20918]: child (19977) Started May 26 05:02:30 proxy-001 varnishd[20918]: Pushing vcls failed:#012CLI communication error (hdr) May 26 05:02:30 proxy-001 varnishd[20918]: Child (19977) said Child starts May 26 05:02:35 proxy-001 varnishd[20918]: Child (19977) said Child dies May 26 05:02:35 proxy-001 varnishd[20918]: Child (19977) died status=1 }}} port is 08 is not listened {{{ PROD/root at proxy-001:~$ netstat -lnp |grep 80 tcp 0 0 0.0.0.0:56806 0.0.0.0:* LISTEN - }}} and only parent process is running {{{ root 20918 0.0 0.0 110296 1084 ? Ss May16 0:00 /usr/sbin/varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 120 -w 400,1000,120 -u varnish -g varnish -s malloc,512M -h critbit -p thread_pools 2 -p thread_pool_add_delay 2 -p listen_depth 1024 -p session_linger 50 -p lru_interval 2 -p shm_reclen 255 -p sess_timeout 30 }}} when stracing parent process it's doing nothing but waiting for some external event or something: {{{ strace -f -p 20918 Process 20918 attached - interrupt to quit poll([{fd=6, events=POLLIN}], 1, -1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Jun 5 16:06:27 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 05 Jun 2013 16:06:27 -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.d4bc7f7301838b09e8a433d93383d539@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 igorm): Hi, i have exactly a same problem. {{{ Jun 5 17:02:19 mweb2 varnishd[25112]: Child (23672) not responding to CLI, killing it. Jun 5 17:02:29 mweb2 varnishd[25112]: Child (23672) not responding to CLI, killing it. Jun 5 17:02:31 mweb2 varnishd[25112]: Child (23672) not responding to CLI, killing it. Jun 5 17:02:31 mweb2 varnishd[25112]: Child (23672) died signal=3 (core dumped) Jun 5 17:02:31 mweb2 varnishd[25112]: Child cleanup complete Jun 5 17:02:31 mweb2 varnishd[25112]: child (23889) Started Jun 5 17:02:32 mweb2 varnishd[25112]: Child (23889) said Child starts Jun 5 17:02:56 mweb2 varnishd[25112]: Child (23889) not responding to CLI, killing it. Jun 5 17:03:06 mweb2 varnishd[25112]: Child (23889) not responding to CLI, killing it. Jun 5 17:03:16 mweb2 varnishd[25112]: Child (23889) not responding to CLI, killing it. Jun 5 17:03:17 mweb2 varnishd[25112]: Child (23889) not responding to CLI, killing it. Jun 5 17:03:17 mweb2 varnishd[25112]: Child (23889) died signal=3 (core dumped) Jun 5 17:03:17 mweb2 varnishd[25112]: Child cleanup complete Jun 5 17:03:17 mweb2 varnishd[25112]: child (24111) Started Jun 5 17:03:27 mweb2 varnishd[25112]: Pushing vcls failed:#012CLI communication error (hdr) Jun 5 17:03:27 mweb2 varnishd[25112]: Stopping Child Jun 5 17:03:27 mweb2 varnishd[25112]: Child (24111) said Child starts Jun 5 17:04:03 mweb2 varnishd[25112]: Child (24111) said Child dies Jun 5 17:04:19 mweb2 varnishd[25112]: Child (24111) died status=1 Jun 5 17:04:19 mweb2 varnishd[25112]: Child cleanup complete }}} Any suggestions? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Jun 6 16:18:50 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 06 Jun 2013 16:18:50 -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.812e2163a47db7d52e0e2c6df1ef2259@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 igorm): Similar problem few minutes ago but on different server {{{ Jun 6 18:08:16 mweb1 varnishd[1278]: Child (1279) not responding to CLI, killing it. Jun 6 18:08:16 mweb1 varnishd[1278]: Child (1279) not responding to CLI, killing it. Jun 6 18:08:16 mweb1 varnishd[1278]: Child (1279) died signal=6 (core dumped) }}} After the warning in syslog, i also saw next exception but it's probably a different issue {{{ Jun 6 18:08:16 mweb1 varnishd[1278]: Child (1279) Panic message: Assert error in vfp_esi_bytes_gg(), cache_esi_fetch.c line 274:#012 Condition(i >= VGZ_OK) not true.#012thread = (cache-worker)#012id ent = Linux,3.2.0-23-generic,x86_64,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x4310e5: /usr/sbin/varnishd() [0x4310e5]#012 0x41e76d: /usr/sbin/varnishd() [0x41e76d]#012 0x41e908: /usr/sbin/v arnishd() [0x41e908]#012 0x4257ac: /usr/sbin/varnishd(FetchBody+0x2ec) [0x4257ac]#012 0x4175c8: /usr/sbin/varnishd() [0x4175c8]#012 0x4192ed: /usr/sbin/varnishd(CNT_Session+0xdad) [0x4192ed]#012 0x432 ee5: /usr/sbin/varnishd() [0x432ee5]#012 0x7f2edbfe0e9a: /lib/x86_64 -linux-gnu/libpthread.so.0(+0x7e9a) [0x7f2edbfe0e9a]#012 0x7f2edbd0e4bd: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f2edbd0e4bd]# 012sp = 0x7f2ed3844008 {#012 fd = 15, id = 15, xid = 1585814891,#012 client = 77.247.201.44 47308,#012 step = STP_FETCHBODY,#012 handling = hit_for_pass,#012 err_code = 206, err_reason = (null),#012 restarts = 0, esi_level = 0#012 flags = do_esi is_gzip#012 bodystatus = 4#012 ws = 0x7f2ed3844080 { #012 id = "sess",#012 {s,f,r,e} = {0x7f2ed3844c78,+584,(nil),+262144},#012 },#012... }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Jun 10 10:30:48 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 10 Jun 2013 10:30:48 -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.be56ebdfa68e846b18ba490f08d9cf0e@varnish-cache.org> #1054: Child not responding to CLI, killing it ---------------------------+----------------------- Reporter: scorillo | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: documentation | Version: 3.0.2 Severity: normal | Resolution: invalid Keywords: | ---------------------------+----------------------- Changes (by phk): * status: reopened => closed * resolution: => invalid Comment: I am closing this ticket as "invalid" for the lack of a better classification. At this point, this ticket is not actionable for us, the underlying issues we have identified have been fixed, while other issues are local performance issue. Please don't reopen this ticket, open a new instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator