From varnish-bugs at varnish-cache.org Mon Dec 2 11:07:02 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Dec 2013 11:07:02 -0000 Subject: [Varnish] #1378: varnishncsa does not escape log items In-Reply-To: <046.c965e13022034e658e261f1b7ddb7f49@varnish-cache.org> References: <046.c965e13022034e658e261f1b7ddb7f49@varnish-cache.org> Message-ID: <061.f3d881c5aec3bf611515309fb7443364@varnish-cache.org> #1378: varnishncsa does not escape log items -------------------------+--------------------- Reporter: simonvik | Owner: martin Type: defect | Status: new Priority: low | Milestone: Component: varnishncsa | Version: 3.0.4 Severity: minor | Resolution: Keywords: | -------------------------+--------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 2 11:28:06 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Dec 2013 11:28:06 -0000 Subject: [Varnish] #1372: Consistent crashes with seg fault error 4 in libc-2.12.so In-Reply-To: <045.a0d66f4881fdf144e127f5a22a64caca@varnish-cache.org> References: <045.a0d66f4881fdf144e127f5a22a64caca@varnish-cache.org> Message-ID: <060.3e95ff3554a8e4454b96e0a3f5277b20@varnish-cache.org> #1372: Consistent crashes with seg fault error 4 in libc-2.12.so ----------------------+------------------------------ Reporter: tomypro | Owner: Type: defect | Status: new Priority: highest | Milestone: Varnish 3.0 dev Component: varnishd | Version: 3.0.4 Severity: blocker | Resolution: Keywords: | ----------------------+------------------------------ Comment (by martin): Hi, The backtrace you sent was a bit incomplete. That line only shows where the crash happened, which was in glibc code. We need to see from where and how it was called through Varnish. So the complete call stack is needed to get anywhere on this issue. Do a 'bt full' from the gdb command line to print the full backtrace. Also the vcl file you are running with would be helpful. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 2 11:30:21 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Dec 2013 11:30:21 -0000 Subject: [Varnish] #1377: varnishlog -I does not play well with -i or -m In-Reply-To: <043.a4846ba07e044099acaa5a616f79536a@varnish-cache.org> References: <043.a4846ba07e044099acaa5a616f79536a@varnish-cache.org> Message-ID: <058.6938a9bcc9ce7e8a54083857c7237267@varnish-cache.org> #1377: varnishlog -I does not play well with -i or -m ---------------------------+--------------------- Reporter: frisi | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: This is fixed by the new API and utilities that will be part of Varnish 4. Closing this ticket. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 2 12:06:57 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Dec 2013 12:06:57 -0000 Subject: [Varnish] #1377: varnishlog -I does not play well with -i or -m In-Reply-To: <043.a4846ba07e044099acaa5a616f79536a@varnish-cache.org> References: <043.a4846ba07e044099acaa5a616f79536a@varnish-cache.org> Message-ID: <058.fecc7eb95095532ce0e92ffacf9b3db7@varnish-cache.org> #1377: varnishlog -I does not play well with -i or -m ---------------------------+--------------------- Reporter: frisi | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Comment (by frisi): thanks for your reply martin. so if i unterstand correctly, this won't be fixed for varnish 3.x series? what's the roadmap for varnish4 like? workaround (if others find this ticket): use grep (but be aware that some output will be delayed until the next requests are logged) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 2 12:33:21 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Dec 2013 12:33:21 -0000 Subject: [Varnish] #1377: varnishlog -I does not play well with -i or -m In-Reply-To: <043.a4846ba07e044099acaa5a616f79536a@varnish-cache.org> References: <043.a4846ba07e044099acaa5a616f79536a@varnish-cache.org> Message-ID: <058.47676d518c392a5de715636644cca42c@varnish-cache.org> #1377: varnishlog -I does not play well with -i or -m ---------------------------+--------------------- Reporter: frisi | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Comment (by martin): Hi, Yeah, that is correctly understood that we don't plan on fixing this for Varnish 3. Varnish 4 will see a tech preview release todayish, with 4.0 released the docs are ready and some real life testing has been done and the bugs ironed out. For the grep workaround, remember that there is an 'unbuffered' option to varnishlog, which will fix the delay problem. Regards, Martin Blix Grydeland -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 2 13:13:37 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Dec 2013 13:13:37 -0000 Subject: [Varnish] #1377: varnishlog -I does not play well with -i or -m In-Reply-To: <043.a4846ba07e044099acaa5a616f79536a@varnish-cache.org> References: <043.a4846ba07e044099acaa5a616f79536a@varnish-cache.org> Message-ID: <058.8639132789c6a9f4e28e3431d935eff0@varnish-cache.org> #1377: varnishlog -I does not play well with -i or -m ---------------------------+--------------------- Reporter: frisi | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishlog | Version: 3.0.4 Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------- Comment (by frisi): thanks for the hint, i'll try the {{{-u}}}} option the next time -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 2 16:55:47 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Dec 2013 16:55:47 -0000 Subject: [Varnish] #1379: Document %D and %T in varnishncsa.1 Message-ID: <043.d2a086d6f0555a26b5087b5a2f763e11@varnish-cache.org> #1379: Document %D and %T in varnishncsa.1 ---------------------+--------------------------- Reporter: lampe | Type: documentation Status: new | Priority: normal Milestone: | Component: varnishncsa Version: unknown | Severity: trivial Keywords: | ---------------------+--------------------------- {{{ --- varnishncsa.1.orig +++ varnishncsa.1 @@ -79,6 +79,9 @@ In CLF format, i.e. a \(aq\-\(aq rather than a 0 when no bytes are sent. .TP +.B %D +Time taken to serve the request, in microseconds. +.TP .B %H The request protocol. Defaults to HTTP/1.0 if not known. @@ -119,6 +122,9 @@ specified by X. The time specification format is the same as for strftime(3). .TP +.B %T +Time taken to serve the request, in seconds. +.TP .B %U The request URL without any query string. Defaults to \(aq\-\(aq if not known. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 3 09:21:11 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Dec 2013 09:21:11 -0000 Subject: [Varnish] #1374: High SWAP usage In-Reply-To: <043.86ef40551613a8c85d41afe6583b5c09@varnish-cache.org> References: <043.86ef40551613a8c85d41afe6583b5c09@varnish-cache.org> Message-ID: <058.d9afcde52c3af12c02268ca7ca2b142c@varnish-cache.org> #1374: High SWAP usage ----------------------+------------------------- Reporter: jammy | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by scoof): * status: new => closed * resolution: => worksforme Comment: Varnish does not decide when to swap, your kernel does. RSS size does not seem to indicate any memory leak issues. There are no indications of a bug in this ticket, so I'm closing it. You should use the varnish-misc mailing list (https://www.varnish- cache.org/lists/mailman/listinfo/varnish-misc) or forums (https://www .varnish-cache.org/forum) for this type of question. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 5 10:45:43 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 05 Dec 2013 10:45:43 -0000 Subject: [Varnish] #1380: esi:request_headers support Message-ID: <050.7ad8956688b36fbc07042bef02c0ea41@varnish-cache.org> #1380: esi:request_headers support -----------------------------+--------------------------- Reporter: lorenzololli | Type: documentation Status: new | Priority: lowest Milestone: Varnish 3.0 dev | Component: documentation Version: 3.0.4 | Severity: normal Keywords: ESI | -----------------------------+--------------------------- Greetings, I'm looking into varnish documentation about ESI, available here https://www.varnish-cache.org/trac/wiki/ESIfeatures but I do not understain if varnish does implement some ESI method. At the very beginning of the guide I read: "Roughly speaking, ESI consists of three parts, of which Varnish so far, implements only one: , and Content substitution based on variables and cookies Caching policy control" but, I cannot get any complete list of all command supported by varnish. In my specific case, I would like to know if ESI implementation of varnish cover the "esi:request_headers" support. Thank you in advance for your help. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 7 11:54:12 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 07 Dec 2013 11:54:12 -0000 Subject: [Varnish] #1349: No exact match on varnishadm backend.set_health In-Reply-To: <046.8a05e196ff21820ddf1411b60bf8db31@varnish-cache.org> References: <046.8a05e196ff21820ddf1411b60bf8db31@varnish-cache.org> Message-ID: <061.73fec95be2698160ca95b52a02f69715@varnish-cache.org> #1349: No exact match on varnishadm backend.set_health --------------------------------------------+-------------------- Reporter: tmagnien | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: normal | Resolution: Keywords: exact match backend.set_health | --------------------------------------------+-------------------- Comment (by jeremyb): https://www.varnish-cache.org/lists/pipermail/varnish- misc/2013-March/022953.html -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Dec 8 16:31:07 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 08 Dec 2013 16:31:07 -0000 Subject: [Varnish] #1381: vmod_director is not installed Message-ID: <043.22adcba4b2a264d9a8dbf1b970028113@varnish-cache.org> #1381: vmod_director is not installed --------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: trunk Severity: normal | Keywords: --------------------+----------------------------- make install doesn't install vmod_director -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 10:45:35 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 10:45:35 -0000 Subject: [Varnish] #1382: varnishncsa prints nulls as part of request string Message-ID: <043.ed6899a233012bb397d4137c08367b10@varnish-cache.org> #1382: varnishncsa prints nulls as part of request string --------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: Severity: normal | Keywords: --------------------+----------------------------- 4.0tp1 varnishncsa out as seen by less: 172.22.51.1 - - [09/Dec/2013:11:13:13 +0100] "GET^@ http://localhost/favicon.ico^@ HTTP/1.1^@" 200^@ 0^@ "-" "-" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 10:47:16 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 10:47:16 -0000 Subject: [Varnish] #1383: varnishncsa logs requests for localhost regardless of host header Message-ID: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> #1383: varnishncsa logs requests for localhost regardless of host header --------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Keywords: --------------------+----------------------------- %r will always print localhost as Host -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 10:49:17 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 10:49:17 -0000 Subject: [Varnish] #1383: varnishncsa logs requests for localhost regardless of host header In-Reply-To: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> References: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> Message-ID: <058.714a98664217aba93b23937ef9f8ecf3@varnish-cache.org> #1383: varnishncsa logs requests for localhost regardless of host header --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by scoof): fwiw, %{Host}i works fine -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 11:07:49 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 11:07:49 -0000 Subject: [Varnish] #1383: varnishncsa logs requests for localhost regardless of host header In-Reply-To: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> References: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> Message-ID: <058.6e62bc39fe444d10136d2b64f60c5cb8@varnish-cache.org> #1383: varnishncsa logs requests for localhost regardless of host header --------------------+------------------------------ Reporter: scoof | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 11:07:53 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 11:07:53 -0000 Subject: [Varnish] #1382: varnishncsa prints nulls as part of request string In-Reply-To: <043.ed6899a233012bb397d4137c08367b10@varnish-cache.org> References: <043.ed6899a233012bb397d4137c08367b10@varnish-cache.org> Message-ID: <058.dc92d0dabc4f479a105f598977bece56@varnish-cache.org> #1382: varnishncsa prints nulls as part of request string --------------------+------------------------------ Reporter: scoof | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 11:18:13 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 11:18:13 -0000 Subject: [Varnish] #1330: VSL_Dispatch parameters 'fd' and 'spec' intermittently called with uninitialized values In-Reply-To: <043.aa626a75c4fe2e02d466c0020d05a41b@varnish-cache.org> References: <043.aa626a75c4fe2e02d466c0020d05a41b@varnish-cache.org> Message-ID: <058.ed43e998f951b9cfb1d1c9eaa6bfc526@varnish-cache.org> #1330: VSL_Dispatch parameters 'fd' and 'spec' intermittently called with uninitialized values ------------------------+--------------------- Reporter: geoff | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: varnishlog | Version: 3.0.3 Severity: major | Resolution: fixed Keywords: | ------------------------+--------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: This is fixed in Varnish 4 with the new API. As there are no trivial way to resolve this in 3.0, any API users with 3.0 code will have to work with and deal with the behavior described here. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 12:25:01 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 12:25:01 -0000 Subject: [Varnish] #1382: varnishncsa prints nulls as part of request string In-Reply-To: <043.ed6899a233012bb397d4137c08367b10@varnish-cache.org> References: <043.ed6899a233012bb397d4137c08367b10@varnish-cache.org> Message-ID: <058.9879bcf14ecf1b6857c5121569022de6@varnish-cache.org> #1382: varnishncsa prints nulls as part of request string --------------------+------------------------------ Reporter: scoof | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by martin): Fixed by 319cb7442fc504e7b43d5f4e834265b700eed7bb Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 12:25:27 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 12:25:27 -0000 Subject: [Varnish] #1383: varnishncsa logs requests for localhost regardless of host header In-Reply-To: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> References: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> Message-ID: <058.f68800a10558b8f4d9e031106d16a2d2@varnish-cache.org> #1383: varnishncsa logs requests for localhost regardless of host header --------------------+------------------------------ Reporter: scoof | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by martin): Fixed by 46c0c379572d5dee5bc345f3aaf3bf83b16eac39 Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 13:00:30 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 13:00:30 -0000 Subject: [Varnish] #1383: varnishncsa logs requests for localhost regardless of host header In-Reply-To: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> References: <043.82682f202681949fc73176bf7a9cc84c@varnish-cache.org> Message-ID: <058.c285f3a0cb91caf1e8ded9fed0457869@varnish-cache.org> #1383: varnishncsa logs requests for localhost regardless of host header --------------------+------------------------------ Reporter: scoof | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------ Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [46c0c379572d5dee5bc345f3aaf3bf83b16eac39]: {{{ #!CommitTicketReference repository="" revision="46c0c379572d5dee5bc345f3aaf3bf83b16eac39" Fix wrong argument order when picking the Host header. Fix wrong argument order for isprefix() when picking the Host header. This caused the header to never be matched. Fixes: #1383 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 13:00:30 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 13:00:30 -0000 Subject: [Varnish] #1382: varnishncsa prints nulls as part of request string In-Reply-To: <043.ed6899a233012bb397d4137c08367b10@varnish-cache.org> References: <043.ed6899a233012bb397d4137c08367b10@varnish-cache.org> Message-ID: <058.4883ffa9e07360fb0b37f89e9d060a95@varnish-cache.org> #1382: varnishncsa prints nulls as part of request string --------------------+------------------------------ Reporter: scoof | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------ Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: In [319cb7442fc504e7b43d5f4e834265b700eed7bb]: {{{ #!CommitTicketReference repository="" revision="319cb7442fc504e7b43d5f4e834265b700eed7bb" Remove log record terminating null char before processing log lines. Fix the end of log record pointer to not include the record terminating null char. This caused the null to be part of the captured fragments and sent to the output. Fixes: #1382 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 15:27:48 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 15:27:48 -0000 Subject: [Varnish] #1384: std.fileread does not refresh file changed on disk Message-ID: <046.0a9bee5969c34a18231e9ea106bcf425@varnish-cache.org> #1384: std.fileread does not refresh file changed on disk --------------------------+---------------------- Reporter: rzuidhof | Type: defect Status: new | Priority: high Milestone: | Component: varnishd Version: 3.0.5 | Severity: major Keywords: std.fileread | --------------------------+---------------------- I found out that std.fileread does not notice changes in the files it reads from disk. The only way to refresh to custom error pages now is to restart the Varnish daemon. Take these lines for example: set obj.http.error404 = std.fileread("/var/www/content/404"); set obj.http.error500 = std.fileread("/var/www/content/500"); I can change which file is read by changing the config and reloading the vcl. But only old file contents is shown until Varnish is restarted. Both Varnish 3.0.4 and 3.0.5 have this issue. Running Varnish (malloc) on RHEL 6.4 with a default mounted ext3 fs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 9 17:37:55 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Dec 2013 17:37:55 -0000 Subject: [Varnish] #1385: ban lurker doesn't remove (G)one bans Message-ID: <043.46bf7ae0a3321559a3aa3bdc6867125b@varnish-cache.org> #1385: ban lurker doesn't remove (G)one bans --------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Keywords: --------------------+----------------------------- They just seem to build up: {{{ Present bans: 1386610235.100173 25178 obj.http.x-url ~ /single_picture/10662/25/.* && obj.http.x-host == fotoagent.dk 1386610209.483904 24111 obj.http.x-url ~ /single_picture/11576/138/.* && obj.http.x-host == fotoagent.dk 1386609957.593609 233588G 1386609934.746460 20998G 1386609864.036771 62060G 1386609821.573339 34334G 1386604014.298002 0G 1386603728.585084 0G 1386603649.333158 0G 1386603649.202651 0G 1386603649.059393 0G 1386603648.944185 0G 1386603648.807588 0G 1386603648.661494 0G 1386603648.538109 0G 1386603648.412835 0G 1386603648.280718 0G 1386603167.687963 0G 1386603013.598530 0G 1386602935.696499 0G 1386602828.373262 0G 1386602824.884062 0G 1386602817.656560 0G 1386602768.317673 0G 1386602763.898830 0G 1386602757.313891 0G 1386602117.745641 0G 1386601906.590645 0G 1386601906.429157 0G 1386601906.317220 0G 1386601680.928821 0G 1386601544.002790 0G 1386601529.462265 0G 1386601521.258648 0G 1386601512.531976 0G 1386601497.985266 0G 1386601482.883328 0G 1386601448.803563 0G 1386601437.302348 0G 1386601434.615610 0G 1386601433.041620 0G 1386601429.318973 0G 1386601422.680830 0G 1386601357.964400 0G 1386601281.734983 0G 1386601111.938352 0G 1386601074.394634 0G 1386600933.825767 0G 1386600931.304149 0G 1386600929.990173 0G 1386600926.307570 0G 1386600920.933889 0G 1386600864.644139 0G 1386600861.354167 0G 1386600853.281608 0G 1386600848.070037 0G 1386600759.036663 0G 1386600752.617243 0G 1386600751.335773 0G }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 10 09:09:29 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Dec 2013 09:09:29 -0000 Subject: [Varnish] #1386: 4.0tp1 crashes around every 6 hours Message-ID: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> #1386: 4.0tp1 crashes around every 6 hours --------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Keywords: --------------------+----------------------------- Dec 10 02:13:31 XXX kernel: [13763692.354742] varnishd[9989]: segfault at d0 ip 000000000042c463 sp 00007f152c226080 error 4 in varnishd[400000+9b000] I will get a backtrace -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 10 09:11:00 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Dec 2013 09:11:00 -0000 Subject: [Varnish] #1386: 4.0tp1 crashes around every 6 hours In-Reply-To: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> References: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> Message-ID: <058.e56268eee6ef9e327a53c302ebd55e9d@varnish-cache.org> #1386: 4.0tp1 crashes around every 6 hours --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by scoof): #0 0x000000000042c463 in HSH_DerefObjCore (ds=Cannot access memory at address 0x7f152c226088 ) at cache/cache_hash.c:796 oc = Cannot access memory at address 0x7f152c2260a0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 10 18:49:32 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Dec 2013 18:49:32 -0000 Subject: [Varnish] #1386: 4.0tp1 crashes around every 6 hours In-Reply-To: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> References: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> Message-ID: <058.130ac5ab630a8652497bcc4a6668d6c6@varnish-cache.org> #1386: 4.0tp1 crashes around every 6 hours --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by scoof): {{{ #0 0x0000000000419374 in VBO_extend (bo=0x7fbf68edb020, l=14205) at cache/cache_busyobj.c:224 #1 0x0000000000426253 in VFP_Fetch_Body (bo=0x7fbf68edb020, est=0) at cache/cache_fetch_proc.c:227 #2 0x00000000004242ce in vbf_stp_fetch (wrk=0x7fc28feaac40, bo=0x7fbf68edb020) at cache/cache_fetch.c:459 #3 0x000000000042508b in vbf_fetch_thread (wrk=0x7fc28feaac40, priv=0x7fbf68edb020) at ../../include/tbl/steps.h:56 #4 0x000000000043a912 in Pool_Work_Thread (priv=0x7fc2bbc0e300, wrk=0x7fc28feaac40) at cache/cache_pool.c:295 #5 0x00000000004534f8 in wrk_thread_real (priv=0x7fc2bbc0e300, thread_workspace=2048) at cache/cache_wrk.c:143 #6 0x0000000000453621 in WRK_thread (priv=0x7fc2bbc0e300) at cache/cache_wrk.c:161 #7 0x00007fc2c6fa08ba in start_thread () from /lib/libpthread.so.0 #8 0x00007fc2c6d0802d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 11 10:44:21 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Dec 2013 10:44:21 -0000 Subject: [Varnish] #1387: p00005.vtc uses transient storage Message-ID: <047.783396d0a75b3d88ddb6bdeb69ab86ca@varnish-cache.org> #1387: p00005.vtc uses transient storage -----------------------+------------------------- Reporter: gquintard | Type: defect Status: new | Priority: normal Milestone: | Component: varnishtest Version: trunk | Severity: normal Keywords: | -----------------------+------------------------- As said on IRC, p00005.vtc doesn't test what it should, and passes for the wrong reasons. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 11 12:06:35 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Dec 2013 12:06:35 -0000 Subject: [Varnish] #1268: 'shortlived' does not consider grace/keep In-Reply-To: <043.b6f261f0eca41d964db078b4b18d6e88@varnish-cache.org> References: <043.b6f261f0eca41d964db078b4b18d6e88@varnish-cache.org> Message-ID: <058.d689b00eb6fc165e9a38bcc85f2dbbd2@varnish-cache.org> #1268: 'shortlived' does not consider grace/keep --------------------+-------------------- Reporter: daghf | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+-------------------- Comment (by gquintard): Update the ttl test in cache_fetch to test ttl+gracce+keep. Had to tweak an assert in storage_persistent.c the same way. Note thish will make p00005.vtc fails if the patch from #1387 is not applied. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 11 14:06:01 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Dec 2013 14:06:01 -0000 Subject: [Varnish] #1379: Document %D and %T in varnishncsa.1 In-Reply-To: <043.d2a086d6f0555a26b5087b5a2f763e11@varnish-cache.org> References: <043.d2a086d6f0555a26b5087b5a2f763e11@varnish-cache.org> Message-ID: <058.8d4fc44dd932a1baea9d236ca3fd10a0@varnish-cache.org> #1379: Document %D and %T in varnishncsa.1 ---------------------------+---------------------- Reporter: lampe | Owner: Type: documentation | Status: closed Priority: normal | Milestone: Component: varnishncsa | Version: unknown Severity: trivial | Resolution: fixed Keywords: | ---------------------------+---------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: in 3.0: commit dd0e69604c26a9a7852d7804d6e75111e06cf6ee Author: Tollef Fog Heen Date: Thu May 2 14:04:22 2013 +0200 Document %D and %T for varnishncsa -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 07:22:49 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 07:22:49 -0000 Subject: [Varnish] #1381: vmod_director is not installed In-Reply-To: <043.22adcba4b2a264d9a8dbf1b970028113@varnish-cache.org> References: <043.22adcba4b2a264d9a8dbf1b970028113@varnish-cache.org> Message-ID: <058.008e6c512261a6113d15818290d1a563@varnish-cache.org> #1381: vmod_director is not installed --------------------+----------------------------------------- Reporter: scoof | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+----------------------------------------- Changes (by Tollef Fog Heen ): * status: new => closed * owner: => Tollef Fog Heen * resolution: => fixed Comment: In [352aea73426cbbc94bb60684f4eaa93317681d5f]: {{{ #!CommitTicketReference repository="" revision="352aea73426cbbc94bb60684f4eaa93317681d5f" Install vmod_director Fixes: #1381 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 11:00:13 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 11:00:13 -0000 Subject: [Varnish] #1388: Length is 0 for cached responses Message-ID: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> #1388: Length is 0 for cached responses --------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Keywords: --------------------+----------------------------- A length of 0 is logged for most responses. Some have a length > 0, but I can't spot the pattern. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 11:01:37 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 11:01:37 -0000 Subject: [Varnish] #1388: Length is 0 for most responses (was: Length is 0 for cached responses) In-Reply-To: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> References: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> Message-ID: <058.4f466bfe815134f9d24ce33b4861df5c@varnish-cache.org> #1388: Length is 0 for most responses --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 11:03:52 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 11:03:52 -0000 Subject: [Varnish] #1388: Length is 0 for most responses In-Reply-To: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> References: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> Message-ID: <058.cff49c928b54f1c3af8ce515454164ab@varnish-cache.org> #1388: Length is 0 for most responses --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by scoof): Content-Length header is correct: {{{ * << Request >> 657418 - Begin req 4295492 - ReqMethod GET - ReqURL XXX - ReqProtocol HTTP/1.1 - ReqHeader Host: XXX - ReqHeader Referer: XXX - ReqHeader Accept-Encoding: gzip, deflate - ReqHeader Accept: */* - ReqHeader Accept-Language: da-dk - ReqHeader Connection: keep-alive - ReqHeader User-Agent: Mozilla/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53 - ReqStart XXX 49192 - VCL_call RECV - VCL_return hash - VCL_call HASH - VCL_return lookup - Hit 2149222362 - VCL_call HIT - VCL_return deliver - VCL_call DELIVER - VCL_return deliver - Debug "RES_MODE 2%00" - RespProtocol HTTP/1.1 - RespStatus 200 - RespResponse OK - RespHeader Server: Apache/2.2.16 (Debian) - RespHeader Last-Modified: Fri, 08 Nov 2013 14:41:34 GMT - RespHeader ETag: "5eafb5a-1b59-4eaab610151e4" - RespHeader Cache-Control: max-age=14400 - RespHeader Access-Control-Allow-Origin: * - RespHeader Content-Type: image/jpeg - RespHeader Date: Thu, 12 Dec 2013 11:02:21 GMT - RespHeader Via: 1.1 varnish - RespHeader X-Varnish: 657418 1738714 varnish01 - RespHeader Content-Length: 7001 - RespHeader Connection: keep-alive - RespHeader Accept-Ranges: bytes - Debug "XXX REF 2%00" - Length 0 - ReqEnd 1386846141.994540930 1386846140.941147327 -1.053476572 0.000082970 -1.053476572 - End }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 11:09:50 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 11:09:50 -0000 Subject: [Varnish] #1389: -q gives different results in varnishncsa and varnishlog Message-ID: <043.fc592940b4d130a00530c48fbb0e776d@varnish-cache.org> #1389: -q gives different results in varnishncsa and varnishlog --------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Keywords: --------------------+----------------------------- varnishlog -q 'Length > 0' logs a lot of requests, while varnishncsa -q 'Length > 0' doesn't log anything. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 12:44:20 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 12:44:20 -0000 Subject: [Varnish] #1389: -q gives different results in varnishncsa and varnishlog In-Reply-To: <043.fc592940b4d130a00530c48fbb0e776d@varnish-cache.org> References: <043.fc592940b4d130a00530c48fbb0e776d@varnish-cache.org> Message-ID: <058.6781df29ac0e8af0698283f98ad37cc5@varnish-cache.org> #1389: -q gives different results in varnishncsa and varnishlog --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------ Changes (by martin): * status: new => closed * resolution: => invalid Comment: In my tests, "varnishlog -q 'Length > 0'" produces a log of bereq transactions only. This because of the bug that makes Length == 0 on most (all?) client request transactions. Varnishncsa will only produce log lines for client transactions. So this is working as intended. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 12:56:32 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 12:56:32 -0000 Subject: [Varnish] #1388: Length is 0 for most responses In-Reply-To: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> References: <043.274a32f05d9b176ccb75ed7082dd7d70@varnish-cache.org> Message-ID: <058.f9f95e904294da381fcd95c053ca843c@varnish-cache.org> #1388: Length is 0 for most responses --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by scoof): As Martin pointed out, backend logs have proper SLT_Length records, but client logs don't -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 15:35:28 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 15:35:28 -0000 Subject: [Varnish] #1390: Assert in ban_mark_gone() Message-ID: <043.852d840d4fd1a44efa908283a6033a31@varnish-cache.org> #1390: Assert in ban_mark_gone() --------------------+----------------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Keywords: --------------------+----------------------------- {{{ Last panic at: Thu, 12 Dec 2013 15:32:22 GMT Assert error in ban_mark_gone(), cache/cache_ban.c line 279: Condition((b->flags & (1<<2)) == 0) not true. thread = (ban-lurker) ident = Linux,2.6.32-5-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43924c: pan_backtrace+0x19 0x43955c: pan_ic+0x1e8 0x414fa7: ban_mark_gone+0x101 0x417e9f: ban_lurker_work+0x19c 0x417fe3: ban_lurker+0x68 0x453886: wrk_bgthread+0xde 0x7fb39d2b08ba: /lib/libpthread.so.0(+0x68ba) [0x7fb39d2b08ba] 0x7fb39d01802d: /lib/libc.so.6(clone+0x6d) [0x7fb39d01802d] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 12 15:59:15 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Dec 2013 15:59:15 -0000 Subject: [Varnish] #1390: Assert in ban_mark_gone() In-Reply-To: <043.852d840d4fd1a44efa908283a6033a31@varnish-cache.org> References: <043.852d840d4fd1a44efa908283a6033a31@varnish-cache.org> Message-ID: <058.94d4e4b09561edd70ecd46997e4067f6@varnish-cache.org> #1390: Assert in ban_mark_gone() --------------------+---------------------------------------- Reporter: scoof | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [58df714a418ecf4144156971001938a9f8880257]: {{{ #!CommitTicketReference repository="" revision="58df714a418ecf4144156971001938a9f8880257" The bans being washed by the ban-lurker can be overtaken by new duplicated bans while it runs. Stumbled on by: scoof Fixes #1390 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 13 12:21:12 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 Dec 2013 12:21:12 -0000 Subject: [Varnish] #1386: 4.0tp1 crashes around every 6 hours In-Reply-To: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> References: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> Message-ID: <058.e84f1438ef71407adeaf8b58dbe92d9d@varnish-cache.org> #1386: 4.0tp1 crashes around every 6 hours --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by scoof): {{{ Last panic at: Fri, 13 Dec 2013 12:04:09 GMT Assert error in VBO_extend(), cache/cache_busyobj.c line 224: Condition((st) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.32-5-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4392c8: pan_backtrace+0x19 0x4395d8: pan_ic+0x1e8 0x41975c: VBO_extend+0x1ac 0x426677: VFP_Fetch_Body+0x2d6 0x4246f2: vbf_stp_fetch+0xcb8 0x4254af: vbf_fetch_thread+0x2f3 0x43ad6a: Pool_Work_Thread+0x429 0x453b5c: wrk_thread_real+0x143 0x453c85: WRK_thread+0x27 0x7fa43785e8ba: /lib/libpthread.so.0(+0x68ba) [0x7fa43785e8ba] busyobj = 0x7fa38488f020 { ws = 0x7fa38488f0f8 { id = "bo", {s,f,r,e} = {0x7fa384891008,+1576,(nil),+57368}, }, is_gzip do_stream bodystatus = 3 (length), }, http[bereq] = { ws = 0x7fa38488f0f8[bo] "", "/webshop/cr7/javasc", "ipts/jqu", "y.easing.1.3.js", " User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) ", "cko/20100101 Firefox/2", "0", "zip, deflate", "w.XXXXXXXXXXXXXXXX/luxury", " Cache", "nection: Keep-Alive", "X-Varnish: 12083288", }, http[beresp] = { ws = 0x7fa38488f0f8[bo] "HTTP/1.1", "200", "OK", "Cache-Control: private", "Content-Type: text/html; charset=utf-8", "Content-Encoding: gzip", "Server: Microsoft-IIS/8.0", "X-AspNet-Version: 4.0.30319", "X-Powered-By: ASP.NET", "X-XXXXXXXXXX: XXXXXXXXXXX", "Date: Fri, 13 Dec 2013 12:03:57 GMT", "Content-Length: 18671", "x-url: XXX", "x-host: XXX", "Vary: Accept-Encoding, Accept-Encoding", }, ws = 0x7fa38488f290 { id = "obj", {s,f,r,e} = {0x7fa38c75aa20,+400,(nil),+408}, }, } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 13 18:06:32 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 13 Dec 2013 18:06:32 -0000 Subject: [Varnish] #1386: 4.0tp1 crashes around every 6 hours In-Reply-To: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> References: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> Message-ID: <058.83e3568030a7553c0598410845d7504d@varnish-cache.org> #1386: 4.0tp1 crashes around every 6 hours --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Comment (by scoof): {{{ Assert error in VFP_Fetch_Body(), cache/cache_fetch_proc.c line 221: Condition(!VTAILQ_EMPTY(&bo->fetch_obj->store)) not true. thread = (cache-worker) ident = Linux,2.6.32-5-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4393f0: pan_backtrace+0x19 0x439700: pan_ic+0x1e8 0x426751: VFP_Fetch_Body+0x331 0x424776: vbf_stp_fetch+0xcb8 0x425533: vbf_fetch_thread+0x2f3 0x43ae92: Pool_Work_Thread+0x429 0x453c84: wrk_thread_real+0x143 0x453dad: WRK_thread+0x27 0x7fc78a5bc8ba: /lib/libpthread.so.0(+0x68ba) [0x7fc78a5bc8ba] 0x7fc78a32402d: /lib/libc.so.6(clone+0x6d) [0x7fc78a32402d] busyobj = 0x7fc6f5fe6020 { ws = 0x7fc6f5fe60f8 { id = "bo", {s,f,r,e} = {0x7fc6f5fe8008,+1600,(nil),+57368}, }, is_gzip do_stream bodystatus = 2 (chunked), }, http[bereq] = { ws = 0x7fc6f5fe60f8[bo] "", "", "", "", "", "", "", "", "", "", "", "X-Varnish: 1723559", }, http[beresp] = { ws = 0x7fc6f5fe60f8[bo] "HTTP/1.1", "200", "OK", "Cache-Control: private", "Transfer-Encoding: chunked", "Content-Type: text/html; charset=utf-8", "Content-Encoding: gzip", "Server: Microsoft-IIS/8.0", "X-AspNet-Version: 4.0.30319", "X-Powered-By: ASP.NET", "X-XXXXXXXXXX: XXXXXXXXXXXX", "Date: Fri, 13 Dec 2013 18:02:40 GMT", "x-url: /XXXXXXXXX/?gclid=XXXXXX", "x-host: www.XXXXXXXX", "Vary: Accept-Encoding, Accept-Encoding", }, ws = 0x7fc6f5fe6290 { id = "obj", {s,f,r,e} = {0x7fc754d8ae10,+400,(nil),+408}, }, } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Dec 15 17:32:04 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 15 Dec 2013 17:32:04 -0000 Subject: [Varnish] #1391: Condition(!VTAILQ_EMPTY(&bo->fetch_obj->store)) not true Message-ID: <046.12b4defb64140e78ee6c3a21b1ca3976@varnish-cache.org> #1391: Condition(!VTAILQ_EMPTY(&bo->fetch_obj->store)) not true ----------------------+----------------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0-TP1 Component: varnishd | Version: unknown Severity: normal | Keywords: ----------------------+----------------------------- While serving a big mpeg file that is being pass-ed, client abort and retry (assumed: while backend fetch is going on) crashes varnishd consistently. Varnishd version is latest git master as of 2013-12-15. {{{ Last panic at: Sun, 15 Dec 2013 17:24:11 GMT Assert error in VFP_Fetch_Body(), cache/cache_fetch_proc.c line 221: Condition(!VTAILQ_EMPTY(&bo->fetch_obj->store)) not true. thread = (cache-worker) ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x4394b0: pan_backtrace+0x19 0x4397ba: pan_ic+0x1e9 0x426823: VFP_Fetch_Body+0x331 0x42486c: vbf_stp_fetch+0xcbf 0x425628: vbf_fetch_thread+0x2fb 0x43af7a: Pool_Work_Thread+0x442 0x453bff: wrk_thread_real+0x152 0x453d28: WRK_thread+0x27 0x7fe1de812b50: /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7fe1de812b50] 0x7fe1de55ca7d: /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fe1de55ca7d] busyobj = 0x1daa2c0 { ws = 0x1daa398 { id = "bo", {s,f,r,e} = {0x1dac2a8,+32784,(nil),+57368}, }, is_gunzip do_stream bodystatus = 3 (length), }, http[bereq] = { ws = 0x1daa398[bo] "", "", "", "", "", "", "", "", "", "", "", "X-Varnish: 3", }, http[beresp] = { ws = 0x1daa398[bo] "HTTP/1.1", "200", "OK", "Server: nginx/1.4.1 (Ubuntu)", "Date: Sun, 15 Dec 2013 17:24:09 GMT", "Content-Type: audio/mpeg", "Content-Length: 165686005", "Last-Modified: Sun, 15 Dec 2013 15:07:54 GMT", "Connection: keep-alive", "ETag: "52adc5ca-9e02af5"", "Accept-Ranges: bytes", }, ws = 0x1daa530 { id = "obj", {s,f,r,e} = {0x1dba608,+264,(nil),+272}, }, } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 16 09:14:20 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Dec 2013 09:14:20 -0000 Subject: [Varnish] #1392: no logging when saintmode denies a backend connection Message-ID: <045.0281c891683c52d234a42d7ec416ce90@varnish-cache.org> #1392: no logging when saintmode denies a backend connection ---------------------+------------------------- Reporter: odoucet | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: unknown | Severity: normal Keywords: | ---------------------+------------------------- Following this discussion on varnish mailing list : https://www.varnish-cache.org/lists/pipermail/varnish- misc/2013-July/023205.html When saintmode denies a backend connection, we only get a 503 error in log with FetchError 'no backend connection'. It should be very useful to know why, and explicit that saintmode did something. Per Buer said he has a patch for this already. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 16 10:57:30 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Dec 2013 10:57:30 -0000 Subject: [Varnish] #1323: suffix-byte-range requests larger than the file size don't work In-Reply-To: <047.84cb6dd391a524ebaf1be3c574302f07@varnish-cache.org> References: <047.84cb6dd391a524ebaf1be3c574302f07@varnish-cache.org> Message-ID: <062.935293735218eebe5ef13dcea2e53eda@varnish-cache.org> #1323: suffix-byte-range requests larger than the file size don't work ---------------------------+-------------------- Reporter: gquintard | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: range request | ---------------------------+-------------------- Changes (by gquintard): * version: 3.0.4 => trunk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 16 13:31:16 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Dec 2013 13:31:16 -0000 Subject: [Varnish] #1391: Condition(!VTAILQ_EMPTY(&bo->fetch_obj->store)) not true In-Reply-To: <046.12b4defb64140e78ee6c3a21b1ca3976@varnish-cache.org> References: <046.12b4defb64140e78ee6c3a21b1ca3976@varnish-cache.org> Message-ID: <061.a1e23915b0eca33973a369b9fb8d5dc5@varnish-cache.org> #1391: Condition(!VTAILQ_EMPTY(&bo->fetch_obj->store)) not true ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: varnishd | Version: unknown Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [b253bf9c52929e13f13c65670dd08871feb1f977]: {{{ #!CommitTicketReference repository="" revision="b253bf9c52929e13f13c65670dd08871feb1f977" When a streaming delivery of a pass object is terminated prematurely, we cannot just throw the storage away, we have to wait for the fetch-thread to go away, possibly in response to a new "abandon" signal. Spotted first by: scoof Fixes #1391 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 16 13:32:10 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Dec 2013 13:32:10 -0000 Subject: [Varnish] #1386: 4.0tp1 crashes around every 6 hours In-Reply-To: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> References: <043.402a329a91c604cf21005fcbbeeef0f5@varnish-cache.org> Message-ID: <058.7e304dde224b225883c44be8b714c657@varnish-cache.org> #1386: 4.0tp1 crashes around every 6 hours --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: duplicate Keywords: | --------------------+------------------------------ Changes (by phk): * status: new => closed * resolution: => duplicate Comment: Duplicate of #1391 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 09:44:34 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 09:44:34 -0000 Subject: [Varnish] #1323: suffix-byte-range requests larger than the file size don't work In-Reply-To: <047.84cb6dd391a524ebaf1be3c574302f07@varnish-cache.org> References: <047.84cb6dd391a524ebaf1be3c574302f07@varnish-cache.org> Message-ID: <062.a278ffba8bc31f88ae38b53453ff0c8a@varnish-cache.org> #1323: suffix-byte-range requests larger than the file size don't work ---------------------------+--------------------- Reporter: gquintard | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: range request | ---------------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * resolution: => fixed Comment: In [9cd74c3b2cbbe499e98394bb80833dc73f4ec943]: {{{ #!CommitTicketReference repository="" revision="9cd74c3b2cbbe499e98394bb80833dc73f4ec943" Add a missing boundary check for Range requests Fixes #1323 Spotted & fix by: gquintard }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 09:50:07 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 09:50:07 -0000 Subject: [Varnish] #1387: p00005.vtc uses transient storage In-Reply-To: <047.783396d0a75b3d88ddb6bdeb69ab86ca@varnish-cache.org> References: <047.783396d0a75b3d88ddb6bdeb69ab86ca@varnish-cache.org> Message-ID: <062.814de3e398f4105b4f05bad991d2470a@varnish-cache.org> #1387: p00005.vtc uses transient storage -------------------------+---------------------------------------- Reporter: gquintard | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtest | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [fc90bf08720af47673d334053270a69c72e94718]: {{{ #!CommitTicketReference repository="" revision="fc90bf08720af47673d334053270a69c72e94718" This test didn't actually use persistent storage because the "shortlived" test puts the object in Transient. Patch by: gquintard Fixes #1387 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 10:19:21 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 10:19:21 -0000 Subject: [Varnish] #1268: 'shortlived' does not consider grace/keep In-Reply-To: <043.b6f261f0eca41d964db078b4b18d6e88@varnish-cache.org> References: <043.b6f261f0eca41d964db078b4b18d6e88@varnish-cache.org> Message-ID: <058.f052805dce255d2278d07c01104db7c6@varnish-cache.org> #1268: 'shortlived' does not consider grace/keep --------------------+--------------------- Reporter: daghf | 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 [e8e208b1095c174e264e138ef24d1dd7f19e2215]: {{{ #!CommitTicketReference repository="" revision="e8e208b1095c174e264e138ef24d1dd7f19e2215" Fix the "shortlived" test to look a the sum of ttl + grace + keep rather than just the ttl. Fixes #1268 Spotted by: daghf Partial fix by: gquintard }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 11:22:22 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 11:22:22 -0000 Subject: [Varnish] #1385: ban lurker doesn't remove (G)one bans In-Reply-To: <043.46bf7ae0a3321559a3aa3bdc6867125b@varnish-cache.org> References: <043.46bf7ae0a3321559a3aa3bdc6867125b@varnish-cache.org> Message-ID: <058.e06550071a3aa22ca3ecfea23f4c4e08@varnish-cache.org> #1385: ban lurker doesn't remove (G)one bans --------------------+------------------------------ Reporter: scoof | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: This is fixed in trunk now. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 11:33:47 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 11:33:47 -0000 Subject: [Varnish] #1229: Varnish Banlurker patch In-Reply-To: <043.574a4f7db89dadc5fc35d65d2f26f366@varnish-cache.org> References: <043.574a4f7db89dadc5fc35d65d2f26f366@varnish-cache.org> Message-ID: <058.31ffc2d1a83932ba921e7269db53aca9@varnish-cache.org> #1229: Varnish Banlurker patch ------------------------------------------------+--------------------- Reporter: celly | Owner: Type: enhancement | Status: closed Priority: high | Milestone: Later Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: fixed Keywords: banlist, huge, performance, lurker | ------------------------------------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: The ban-lurker in -trunk has been rewritten, based in part on this work. I belive the new code is better than the code in these patches in several ways, but primarily in that it does not waste as much effort as the previous (or patched) ban-lurker. There are still areas that could be improved, but I want to get some experience collected with the new ban-lurker to judge cost/benefit of those ideas before I implement them. I'm closing this ticket now, but I hope you will help test out the ban- lurker in -trunk, and provide feedback on how it works for you. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 11:34:32 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 11:34:32 -0000 Subject: [Varnish] #1369: Spinning thread while esi+gzip fetch In-Reply-To: <046.a959baf0eee18a6849c8587f6527406f@varnish-cache.org> References: <046.a959baf0eee18a6849c8587f6527406f@varnish-cache.org> Message-ID: <061.cfda507a7c200d86c03737ea5cde485e@varnish-cache.org> #1369: Spinning thread while esi+gzip fetch ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.4 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by phk): I belive this is fixed in -trunk, can you please try to confirm that ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 11:51:28 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 11:51:28 -0000 Subject: [Varnish] #416: Segfault In-Reply-To: <041.42f511fe181f99ea7e2c7534cd763727@varnish-cache.org> References: <041.42f511fe181f99ea7e2c7534cd763727@varnish-cache.org> Message-ID: <056.89ca6544a4b756eb790b2b500d102a7b@varnish-cache.org> #416: Segfault --------------------+--------------------- Reporter: sky | Owner: sky Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | --------------------+--------------------- Changes (by Poul-Henning Kamp ): * status: reopened => closed * resolution: => fixed Comment: In [15d6c830476bda06c40dbb70ee4bd6be38d6e93e]: {{{ #!CommitTicketReference repository="" revision="15d6c830476bda06c40dbb70ee4bd6be38d6e93e" When we get a bogus reply from a backend, for instance with too many headers, we need to purge all traces of it, before we construct our 503 response, otherwise we risk failing to set important headers, such as "Connection: close". Fixes #416 (again) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 12:22:00 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 12:22:00 -0000 Subject: [Varnish] #1229: Varnish Banlurker patch In-Reply-To: <043.574a4f7db89dadc5fc35d65d2f26f366@varnish-cache.org> References: <043.574a4f7db89dadc5fc35d65d2f26f366@varnish-cache.org> Message-ID: <058.3cf03a9cafc34a5b9904fcff92d08ca9@varnish-cache.org> #1229: Varnish Banlurker patch ------------------------------------------------+--------------------- Reporter: celly | Owner: Type: enhancement | Status: closed Priority: high | Milestone: Later Component: varnishd | Version: 3.0.3 Severity: critical | Resolution: fixed Keywords: banlist, huge, performance, lurker | ------------------------------------------------+--------------------- Comment (by celly): Since I open this ticket, I had to make another patch, much better than this. It can remove all gone bans, not only gone bans to first not gone. I forked you on GIThub. Surely will test your patch, but with mine patch, I can limit maximum gone BANs in list. It is works just fine for us and is able to hold the number of BANs in list pretty low. My github fork if anyone is interested https://github.com/bbcelly/Varnish- Cache -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 15:58:21 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 15:58:21 -0000 Subject: [Varnish] #1393: segfault in varnish tools (but varnish is running fine) Message-ID: <053.c3c1a4a06aa4f7d4747421bb7f99b905@varnish-cache.org> #1393: segfault in varnish tools (but varnish is running fine) -----------------------------+------------------------ Reporter: brandonwamboldt | Type: defect Status: new | Priority: normal Milestone: | Component: varnishlog Version: 3.0.2 | Severity: major Keywords: | -----------------------------+------------------------ I am getting a segmentation fault in all varnish tools (varnishlog, varnishstat, etc) when varnish is running fine. This does not always occur. For example, it'll happen, I'll restart Varnish 3-4 times with no other changes, and then it'll work. Varnish 3.0.2 revision cbf1284 Ubuntu 12.04.3 LTS I'm pretty new to debugging stuff like this, but here is some info. Strace Output: {{{ > strace varnishtop -d -d execve("/usr/bin/varnishtop", ["varnishtop", "-d", "-d"], [/* 36 vars */]) = 0 brk(0) = 0x10c5000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f38138c0000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/varnish/tls/x86_64/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib/varnish/tls/x86_64", 0x7fff09847900) = -1 ENOENT (No such file or directory) open("/usr/lib/varnish/tls/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib/varnish/tls", 0x7fff09847900) = -1 ENOENT (No such file or directory) open("/usr/lib/varnish/x86_64/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib/varnish/x86_64", 0x7fff09847900) = -1 ENOENT (No such file or directory) open("/usr/lib/varnish/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib/varnish", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=26606, ...}) = 0 mmap(NULL, 26606, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f38138b9000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0 \0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=74232, ...}) = 0 mmap(NULL, 2169264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f381348e000 mprotect(0x7f381349f000, 2093056, PROT_NONE) = 0 mmap(0x7f381369e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10000) = 0x7f381369e000 close(3) = 0 open("/usr/lib/varnish/libncurses.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libncurses.so.5", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260Y\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=133808, ...}) = 0 mmap(NULL, 2229440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f381326d000 mprotect(0x7f381328c000, 2097152, PROT_NONE) = 0 mmap(0x7f381348c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f000) = 0x7f381348c000 close(3) = 0 open("/usr/lib/varnish/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\301\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=159200, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f38138b8000 mmap(NULL, 2255936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3813046000 mprotect(0x7f3813068000, 2097152, PROT_NONE) = 0 mmap(0x7f3813268000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f3813268000 close(3) = 0 open("/usr/lib/varnish/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200l\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=135366, ...}) = 0 mmap(NULL, 2212904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3812e29000 mprotect(0x7f3812e41000, 2093056, PROT_NONE) = 0 mmap(0x7f3813040000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f3813040000 mmap(0x7f3813042000, 13352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3813042000 close(3) = 0 open("/usr/lib/varnish/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\30\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1815224, ...}) = 0 mmap(NULL, 3929304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3812a69000 mprotect(0x7f3812c1e000, 2097152, PROT_NONE) = 0 mmap(0x7f3812e1e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b5000) = 0x7f3812e1e000 mmap(0x7f3812e24000, 17624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3812e24000 close(3) = 0 open("/usr/lib/varnish/libpcre.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\25\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=247896, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f38138b7000 mmap(NULL, 2343080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f381282c000 mprotect(0x7f3812868000, 2093056, PROT_NONE) = 0 mmap(0x7f3812a67000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3b000) = 0x7f3812a67000 close(3) = 0 open("/usr/lib/varnish/libdl.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=14768, ...}) = 0 mmap(NULL, 2109704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3812628000 mprotect(0x7f381262a000, 2097152, PROT_NONE) = 0 mmap(0x7f381282a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f381282a000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f38138b6000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f38138b5000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f38138b4000 arch_prctl(ARCH_SET_FS, 0x7f38138b5700) = 0 mprotect(0x7f3812e1e000, 16384, PROT_READ) = 0 mprotect(0x7f381282a000, 4096, PROT_READ) = 0 mprotect(0x7f3812a67000, 4096, PROT_READ) = 0 mprotect(0x7f3813040000, 4096, PROT_READ) = 0 mprotect(0x7f3813268000, 16384, PROT_READ) = 0 mprotect(0x7f381348c000, 4096, PROT_READ) = 0 mprotect(0x7f381369e000, 4096, PROT_READ) = 0 mprotect(0x602000, 4096, PROT_READ) = 0 mprotect(0x7f38138c2000, 4096, PROT_READ) = 0 munmap(0x7f38138b9000, 26606) = 0 set_tid_address(0x7f38138b59d0) = 688 set_robust_list(0x7f38138b59e0, 0x18) = 0 futex(0x7fff098481fc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f38138b5700) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7f3812e2f750, [], SA_RESTORER|SA_SIGINFO, 0x7f3812e38cb0}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7f3812e2f7e0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f3812e38cb0}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x10c5000 brk(0x10e6000) = 0x10e6000 uname({sys="Linux", node="epix.varnish", ...}) = 0 open("/var/lib/varnish/epix.varnish/_.vsm", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=84934656, ...}) = 0 read(3, "6\332y\371\200\0\1\0007q\260R\0\0\0\0\331w\0\0\332w\0\0\0\0\20\5\0\0\0\0"..., 65728) = 65728 mmap(NULL, 84934656, PROT_READ, MAP_SHARED, 3, 0) = 0x7f380d528000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped) }}} GDB Backtrace: {{{ #0 0x00007ffff7bd05a5 in VSL_Open () from /usr/lib/libvarnishapi.so.1 #1 0x0000000000401609 in ?? () #2 0x00007ffff760c76d in __libc_start_main () from /lib/x86_64-linux- gnu/libc.so.6 #3 0x0000000000401965 in ?? () #4 0x00007fffffffe7d8 in ?? () #5 0x000000000000001c in ?? () #6 0x0000000000000001 in ?? () #7 0x00007fffffffea7d in ?? () #8 0x0000000000000000 in ?? () }}} And here's strace output when it works ok: {{{ > strace varnishlog execve("/usr/bin/varnishlog", ["varnishlog"], [/* 36 vars */]) = 0 brk(0) = 0x1eb7000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97c082b000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/varnish/tls/x86_64/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib/varnish/tls/x86_64", 0x7fff3ba67dd0) = -1 ENOENT (No such file or directory) open("/usr/lib/varnish/tls/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib/varnish/tls", 0x7fff3ba67dd0) = -1 ENOENT (No such file or directory) open("/usr/lib/varnish/x86_64/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib/varnish/x86_64", 0x7fff3ba67dd0) = -1 ENOENT (No such file or directory) open("/usr/lib/varnish/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/usr/lib/varnish", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=26606, ...}) = 0 mmap(NULL, 26606, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f97c0824000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libvarnishapi.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0 \0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=74232, ...}) = 0 mmap(NULL, 2169264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97c03f9000 mprotect(0x7f97c040a000, 2093056, PROT_NONE) = 0 mmap(0x7f97c0609000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10000) = 0x7f97c0609000 close(3) = 0 open("/usr/lib/varnish/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200l\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=135366, ...}) = 0 mmap(NULL, 2212904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97c01dc000 mprotect(0x7f97c01f4000, 2093056, PROT_NONE) = 0 mmap(0x7f97c03f3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f97c03f3000 mmap(0x7f97c03f5000, 13352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f97c03f5000 close(3) = 0 open("/usr/lib/varnish/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\30\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1815224, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97c0823000 mmap(NULL, 3929304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97bfe1c000 mprotect(0x7f97bffd1000, 2097152, PROT_NONE) = 0 mmap(0x7f97c01d1000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b5000) = 0x7f97c01d1000 mmap(0x7f97c01d7000, 17624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f97c01d7000 close(3) = 0 open("/usr/lib/varnish/libpcre.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\25\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=247896, ...}) = 0 mmap(NULL, 2343080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f97bfbdf000 mprotect(0x7f97bfc1b000, 2093056, PROT_NONE) = 0 mmap(0x7f97bfe1a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3b000) = 0x7f97bfe1a000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97c0822000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97c0821000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97c0820000 arch_prctl(ARCH_SET_FS, 0x7f97c0821700) = 0 mprotect(0x7f97c01d1000, 16384, PROT_READ) = 0 mprotect(0x7f97bfe1a000, 4096, PROT_READ) = 0 mprotect(0x7f97c03f3000, 4096, PROT_READ) = 0 mprotect(0x7f97c0609000, 4096, PROT_READ) = 0 mprotect(0x604000, 4096, PROT_READ) = 0 mprotect(0x7f97c082d000, 4096, PROT_READ) = 0 munmap(0x7f97c0824000, 26606) = 0 set_tid_address(0x7f97c08219d0) = 5706 set_robust_list(0x7f97c08219e0, 0x18) = 0 futex(0x7fff3ba686cc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f97c0821700) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7f97c01e2750, [], SA_RESTORER|SA_SIGINFO, 0x7f97c01ebcb0}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7f97c01e27e0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f97c01ebcb0}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x1eb7000 brk(0x1ed8000) = 0x1ed8000 uname({sys="Linux", node="epix.varnish", ...}) = 0 open("/var/lib/varnish/epix.varnish/_.vsm", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=84934656, ...}) = 0 read(3, "6\332y\371\200\0\1\0\337s\260R\0\0\0\0\365\21\0\0\366\21\0\0\0\0\20\5\0\0\0\0"..., 65728) = 65728 mmap(NULL, 84934656, PROT_READ, MAP_SHARED, 3, 0) = 0x7f97baadf000 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 nanosleep({0, 50000000}, NULL) = 0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 16:08:23 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 16:08:23 -0000 Subject: [Varnish] #1393: segfault in varnish tools (but varnish is running fine) In-Reply-To: <053.c3c1a4a06aa4f7d4747421bb7f99b905@varnish-cache.org> References: <053.c3c1a4a06aa4f7d4747421bb7f99b905@varnish-cache.org> Message-ID: <068.5ae194abcd8630ba30fa1354501ba561@varnish-cache.org> #1393: segfault in varnish tools (but varnish is running fine) -----------------------------+-------------------- Reporter: brandonwamboldt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 3.0.2 Severity: major | Resolution: Keywords: | -----------------------------+-------------------- Comment (by brandonwamboldt): It also stops segfaulting after varnish has been running for a while. I can't figure out how to get a core dump though. Also, its AMD64 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 16:12:48 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 16:12:48 -0000 Subject: [Varnish] #1393: segfault in varnish tools (but varnish is running fine) In-Reply-To: <053.c3c1a4a06aa4f7d4747421bb7f99b905@varnish-cache.org> References: <053.c3c1a4a06aa4f7d4747421bb7f99b905@varnish-cache.org> Message-ID: <068.a8f250c013192130f601eaf5359c3743@varnish-cache.org> #1393: segfault in varnish tools (but varnish is running fine) -----------------------------+-------------------- Reporter: brandonwamboldt | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 3.0.2 Severity: major | Resolution: Keywords: | -----------------------------+-------------------- Comment (by brandonwamboldt): Syslog stuff: {{{ Dec 17 12:05:39 epix kernel: [13784776.995703] varnishlog[10911]: segfault at 7ff5c420ce8c ip 00007ff5c49f25a5 sp 00007fffbecbae00 error 4 in libvarnishapi.so.1.0.0[7ff5c49ea000+11000] Dec 17 12:07:09 epix kernel: [13784866.254634] varnishlog[11377]: segfault at 7fb950a27e8c ip 00007fb95120d5a5 sp 00007fffde7b7970 error 4 in libvarnishapi.so.1.0.0[7fb951205000+11000] Dec 17 12:07:24 epix kernel: [13784881.375887] varnishlog[11417]: segfault at 7fd964b82e8c ip 00007fd9653685a5 sp 00007fff2126c3f0 error 4 in libvarnishapi.so.1.0.0[7fd965360000+11000] Dec 17 12:09:03 epix kernel: [13784980.952201] varnishlog[11444]: segfault at 7fc25383be8c ip 00007fc2540215a5 sp 00007fff2519d660 error 4 in libvarnishapi.so.1.0.0[7fc254019000+11000] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 17 19:13:33 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Dec 2013 19:13:33 -0000 Subject: [Varnish] #1394: Add conf.d/*.vcl directive to config system Message-ID: <050.17c3b265f7939f94c7de9be81236efd9@varnish-cache.org> #1394: Add conf.d/*.vcl directive to config system --------------------------+------------------------- Reporter: michaelfavia | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: config | --------------------------+------------------------- I looked through the history and didnt find mention of it but i assume this was a possible design decision because it seem like pretty low hanging fruit. Using varnish in a package managed environment and would really appreciate the ability to systematically add varnish configs with a /etc/varnish/conf.d/YOUR_FILE_NAME_HERE.vcl directory. The base default.vcl config file doesnt even have to leverage it if you dont like but there are a good number of requests for it out the downstream in Debian, Fedora, etc as well. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506067 I think the paradigm is well known enough but it very simply allows other packages to add their own configuration logic without the need to append or otherwise edit a file that has to be shared across multiple packaging systems. Apache, php, cron and other systems use it as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 18 09:50:54 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Dec 2013 09:50:54 -0000 Subject: [Varnish] #1395: vcl_error is not called if fetch failed on vcl_backend_fetch Message-ID: <043.08951e6dbd6d7ac15da515243c6db095@varnish-cache.org> #1395: vcl_error is not called if fetch failed on vcl_backend_fetch -------------------+---------------------- Reporter: fgsch | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | -------------------+---------------------- The attached test shows the bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 18 10:35:05 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Dec 2013 10:35:05 -0000 Subject: [Varnish] #1394: Add conf.d/*.vcl directive to config system In-Reply-To: <050.17c3b265f7939f94c7de9be81236efd9@varnish-cache.org> References: <050.17c3b265f7939f94c7de9be81236efd9@varnish-cache.org> Message-ID: <065.8bb729a1c61921eb1bad8420f169fdd7@varnish-cache.org> #1394: Add conf.d/*.vcl directive to config system --------------------------+-------------------- Reporter: michaelfavia | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: config | --------------------------+-------------------- Comment (by ulistaerk): you can load a config use include . this already works. I think you want that the include-statement is capable of loading multiple matching files using glob: include "dir/*.vcl". You have to be aware, that the order of config files is important. Varnish will fail to start, if you define unused code. Other services like apache done. So I dont think is is a good feature - it will unforseen errors. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 18 15:23:39 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Dec 2013 15:23:39 -0000 Subject: [Varnish] #1372: Consistent crashes with seg fault error 4 in libc-2.12.so In-Reply-To: <045.a0d66f4881fdf144e127f5a22a64caca@varnish-cache.org> References: <045.a0d66f4881fdf144e127f5a22a64caca@varnish-cache.org> Message-ID: <060.96660aa5d6b41ca0a0082cbfbc8aa580@varnish-cache.org> #1372: Consistent crashes with seg fault error 4 in libc-2.12.so ----------------------+------------------------------ Reporter: tomypro | Owner: Type: defect | Status: new Priority: highest | Milestone: Varnish 3.0 dev Component: varnishd | Version: 3.0.4 Severity: blocker | Resolution: Keywords: | ----------------------+------------------------------ Comment (by tomypro): I will be providing the requested additional details shortly. /T -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 19 12:04:41 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Dec 2013 12:04:41 -0000 Subject: [Varnish] #1381: vmod_director is not installed In-Reply-To: <043.22adcba4b2a264d9a8dbf1b970028113@varnish-cache.org> References: <043.22adcba4b2a264d9a8dbf1b970028113@varnish-cache.org> Message-ID: <058.46f2dcc1b43637a92e68e527bad57bbd@varnish-cache.org> #1381: vmod_director is not installed --------------------+----------------------------------------- Reporter: scoof | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0-TP1 Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+----------------------------------------- Comment (by kriller): I assume that this is why vmod_director is not included in the debian packages og 4.0.0-tp1 as well? Any chance of seeing updated debian packages that includes vmod_director? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 19 14:35:39 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Dec 2013 14:35:39 -0000 Subject: [Varnish] #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. Message-ID: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. -------------------+---------------------- Reporter: geoff | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.3 | Severity: major Keywords: gzip | -------------------+---------------------- Varnish in production crashed with the assert error shown above, will attach the panic log. {{{ Linux,2.6.32-358.23.2.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit varnish-3.0.3 revision 8452331 }}} This is Varnish 3.0.3 with various custom enhancements, but none of these affect gzip. This happens after an error status is returned from deflateInit2() from zlib; it might be better to throw a 503 when this happens, to avoid the crash. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 19 14:48:55 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Dec 2013 14:48:55 -0000 Subject: [Varnish] #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. In-Reply-To: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> References: <043.e5d283d5da438ce5596863c2de91fce8@varnish-cache.org> Message-ID: <058.8755985ab60462be24517af708fea8b3@varnish-cache.org> #1396: Assert error in VGZ_NewGzip(), cache_gzip.c line 209: Condition(Z_OK == i) not true. ----------------------+-------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 3.0.3 Severity: major | Resolution: Keywords: gzip | ----------------------+-------------------- Comment (by geoff): Some sensitive data in the panic.log has been masked. The crash happened once in production some time ago (there may have been a billion requests since then), so the problem is not urgent. zlib may have attempted a malloc that failed -- errno is ENOMEM, and one of the possible return codes from deflateInit2() is Z_MEM_ERROR (not enough memory). I think that varnishd can throw a 503 error when this happens, rather than crashing. That would have the added benefit that the return value from deflateInit2() could be recorded in the log, making it easier to understand what the problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 20 12:23:30 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Dec 2013 12:23:30 -0000 Subject: [Varnish] #1397: Assert error in vbf_stp_condfetch(), cache/cache_fetch.c line 635: Condition(obj->len == al) not true. Message-ID: <043.061aecbbdcc366bcf2ba6b76f21fb1c5@varnish-cache.org> #1397: Assert error in vbf_stp_condfetch(), cache/cache_fetch.c line 635: Condition(obj->len == al) not true. --------------------+--------------------- Reporter: scoof | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- {{{ Last panic at: Fri, 20 Dec 2013 12:09:25 GMT Assert error in vbf_stp_condfetch(), cache/cache_fetch.c line 635: Condition(obj->len == al) not true. thread = (cache-worker) ident = Linux,2.6.32-5-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x439518: pan_backtrace+0x19 0x439828: pan_ic+0x1e8 0x425225: vbf_stp_condfetch+0x64d 0x425587: vbf_fetch_thread+0x2db 0x43afba: Pool_Work_Thread+0x429 0x453e5c: wrk_thread_real+0x143 0x453f85: WRK_thread+0x27 0x7fbb420528ba: /lib/libpthread.so.0(+0x68ba) [0x7fbb420528ba] 0x7fbb41dba02d: /lib/libc.so.6(clone+0x6d) [0x7fbb41dba02d] busyobj = 0x7fb6b454c020 { ws = 0x7fb6b454c0f8 { id = "bo", {s,f,r,e} = {0x7fb6b454e010,+416,(nil),+57360}, }, do_stream bodystatus = 0 (none), }, http[bereq] = { ws = 0x7fb6b454c0f8[bo] "GET", "XXX", "HTTP/1.1", "Host: XXX", "Referer: XXX", "Accept: */*", "Accept-Language: da-dk", "User-Agent: Mozilla/5.0 (iPad; CPU OS 7_0_3 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B511 Safari/9537.53", "X-Forwarded-For: XXX", "Accept-Encoding: gzip", "If-Modified-Since: Wed, 12 Jun 2013 06:31:09 GMT", "X-Varnish: 15959289", }, http[beresp] = { ws = 0x7fb6b454c0f8[bo] "HTTP/1.1", "304", "Not Modified", "Date: Fri, 20 Dec 2013 12:00:48 GMT", "Server: Apache/2.2.16 (Debian)", "ETag: "823c3e66-2155a-4deef28bf0540"", "Cache-Control: max-age=14400", "Content-Length: 136538", "x-url: /XXX", "x-host: XXX", }, ws = 0x7fb6b454c298 { id = "obj", {s,f,r,e} = {0x7fb6a82df248,+344,(nil),+344}, }, } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 27 14:24:20 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Dec 2013 14:24:20 -0000 Subject: [Varnish] #1398: Assert error in VRT_r_beresp_backend_name(), cache/cache_vrt_var.c Message-ID: <059.60efee19c4ef65c9297e7b5d100abaf4@varnish-cache.org> #1398: Assert error in VRT_r_beresp_backend_name(), cache/cache_vrt_var.c -------------------------------------------------+------------------------- Reporter: varnish@? | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0-TP1 | Component: varnishd Version: trunk | Severity: normal Keywords: assert assertion | VRT_r_beresp_backend_name | -------------------------------------------------+------------------------- Hi, a assertion is thrown, if you're using a the following VCL code inside vcl_backend_response (this code snippet is for debugging purposes) and a backend fetch error occures: {{{ # save some information for later use set beresp.http.X-BE-Name = beresp.backend.name; }}} The assertion is the following: {{{ Panic message: Assert error in VRT_r_beresp_backend_name(), cache/cache_vrt_var.c line 253: Condition((ctx->bo->vbc) != NULL) not true. thread = (cache-worker) ident = Linux,2.6.32-431.el6.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x437b83: pan_backtrace+0x19 0x437e93: pan_ic+0x1e8 0x44d7c8: VRT_r_beresp_backend_name+0x134 0x7fdc6c6ebed5: ./vcl._JEAaMEX.so(VGC_function_vcl_backend_response+0x25) [0x7fdc6c6ebed5] 0x445c1f: vcl_call_method+0x402 0x446bca: VCL_backend_response_method+0x128 0x422823: vbf_stp_fetchhdr+0x530 0x4242c6: vbf_fetch_thread+0x2c3 0x439607: Pool_Work_Thread+0x416 0x4520e4: wrk_thread_real+0x143 busyobj = 0x7fdc44090a90 { ws = 0x7fdc44090b30 { id = "bo", {s,f,r,e} = {0x7fdc44092a58,+96,(nil),+57400}, }, do_stream should_close bodystatus = 0 (none), }, http[bereq] = { ws = 0x7fdc44090b30[bo] "GET", "", "HTTP/1.1", "", "", "", "", "", "", "", "Accept-Encoding: gzip", "If-Modified-Since: Mon, 30 May 2011 10:02:31 GMT", "X-Varnish: 6", "Host: 192.168.0.45", }, http[beresp] = { ws = 0x7fdc44090b30[bo] "HTTP/1.1", "Backend fetch failed", "Content-Length: 0", "Connection: close", }, ws = 0x7fdc44090cd8 { id = "(null)", {s,f,r,e} = {(nil),(nil),(nil),(nil)}, }, } }}} It seems that the backend error isn't handled gracefully inside vbf_stp_fetchhdr() - cache/cache_fetch.c, thus the normal request flow is continued, till the assertion occures. Best regards, Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 27 22:40:45 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Dec 2013 22:40:45 -0000 Subject: [Varnish] #1399: Memory get freed while in use by another thread/object Message-ID: <059.1e289aaa7c9164a8a63898e6d8c12f43@varnish-cache.org> #1399: Memory get freed while in use by another thread/object -------------------------------------------------+------------------------- Reporter: varnish@? | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0-TP1 | Component: varnishd Version: trunk | Severity: major Keywords: memory get freed MPL_Free | vbf_stp_fetchhdr | -------------------------------------------------+------------------------- Hi, prerequisites: - compiled varnishd via "./configure --enable-debugging-symbols --without-jemalloc" - start varnishd from commandline {{{ varnishd -n VARNISH -f default.vcl -n /var/tmp/ -a :8080 -p default_grace=10 -p default_ttl=5 -p ping_interval=0 -p auto_restart=off -d }}} - start the child process via start - configure a single backend w/o health probes - start two consecutive requests to varnish with a pause of $backend_keepalive_timeout + 1 second - backend is a apache httpd with 10s keepalive timeout while debugging issue #1398 I've found another issue, which was a little bit more complicated to debug. While a backend request is made, the busyobject bereq structures get filled by the following functions: - vbf_stp_mkbereq -> bo->bereq0 get populted from bo->req->http - vbf_stp_startfetch -> bo->bereq get copied from bo->bereq0 After this was done, the headers will be fetched from backend via vbf_stp_fetchhdr. After the first request was made, a new object will saved by varnish. If you now wait for the keep alive timeout of your backend and then starting the second request, the object will be gracefully delivered by varnish to the client, but the ongoing backend request will fail, because another thread has freed the initial (?) req object from memory. The result is, that the backend responses with an error or in a virtualhost environment the first vhost which matches the backend ip. You can see the bereq structur in ticket #1398, the URL and some headers get deleted from the bereq structure. For me it looks like the problem leys in vbf_stp_startfetch(), where the bo->bereq structure will be copied from the bo->bereq0 object. Either the header should be duplicated, since the protocol and method get also duplicated (but this could be for conditional fetches) or the req object inside the busyobject structure should be protected from improper invalidation (disclaimer: this opinion could be totally wrong). I've found this bug with the help of gdb, following my commands which I've executed: {{{ (gdb) b vbf_stp_fetchhdr Breakpoint 1 at 0x422304: file cache/cache_fetch.c, line 148. (gdb) c Continuing. [Switching to Thread 0x7f853931b700 (LWP 11382)] Breakpoint 1, vbf_stp_fetchhdr (wrk=0x7f853931ac20, bo=0x7f851c090a90) at cache/cache_fetch.c:148 148 CHECK_OBJ_NOTNULL(wrk, WORKER_MAGIC); (gdb) c Continuing. Breakpoint 1, vbf_stp_fetchhdr (wrk=0x7f853931ac20, bo=0x7f851c090a90) at cache/cache_fetch.c:148 148 CHECK_OBJ_NOTNULL(wrk, WORKER_MAGIC); (gdb) p bo->bereq->hd[1] $3 = {b = 0x7f8510092a6d "/", e = 0x7f8510092a6e ""} (gdb) p bo->bereq->hd[1].b $4 = 0x7f8510092a6d "/" (gdb) watch *0x7f8510092a6d Hardware watchpoint 2: *0x7f8510092a6d (gdb) c Continuing. [Switching to Thread 0x7f85392f7700 (LWP 11385)] Hardware watchpoint 2: *0x7f8510092a6d Old value = 1414004783 New value = 1409286144 __memset_sse2 () at ../sysdeps/x86_64/memset.S:880 880 movdqa %xmm0,0x60(%rdi) (gdb) bt #0 __memset_sse2 () at ../sysdeps/x86_64/memset.S:880 #1 0x0000000000435eec in MPL_Free (mpl=0x7f8534000a20, item=0x7f8510090a90) at cache/cache_mempool.c:322 #2 0x0000000000441ed2 in SES_ReleaseReq (req=0x7f8510090a90) at cache/cache_session.c:437 #3 0x000000000042ff5f in http1_wait (sp=0x7f8514001540, wrk=0x7f85392f6c20, req=0x7f8510090a90) at cache/cache_http1_fsm.c:159 #4 0x0000000000431106 in HTTP1_Session (wrk=0x7f85392f6c20, req=0x7f8510090a90) at cache/cache_http1_fsm.c:437 #5 0x000000000044062e in ses_req_pool_task (wrk=0x7f85392f6c20, arg=0x7f8510090a90) at cache/cache_session.c:148 #6 0x0000000000440856 in ses_sess_pool_task (wrk=0x7f85392f6c20, arg=0x7f8514001540) at cache/cache_session.c:173 #7 0x0000000000440d69 in SES_pool_accept_task (wrk=0x7f85392f6c20, arg=0x7f85340009f0) at cache/cache_session.c:243 #8 0x0000000000439607 in Pool_Work_Thread (priv=0x7f85340008c0, wrk=0x7f85392f6c20) at cache/cache_pool.c:295 #9 0x00000000004520e4 in wrk_thread_real (priv=0x7f85340008c0, thread_workspace=2048) at cache/cache_wrk.c:143 #10 0x000000000045220d in WRK_thread (priv=0x7f85340008c0) at cache/cache_wrk.c:161 #11 0x00007f854d8349d1 in start_thread (arg=0x7f85392f7700) at pthread_create.c:301 #12 0x00007f854d581b6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) q }}} 1. attach to the child 2. set a breakpoint to vbf_stp_fetchhdr() 3. start the first request in another terminal 4. continue this execution of vbf_stp_fetchhdr() - it's the first request which works 5. start the second request in another terminal 6. print the memory address of the header we want to watch 7. set the wwatchpoint for the memory address which holds our important value 8. continue execution 9. watchpoint will be trapped by another thread which deallocates the req structures Please let me know if you need more information. Best regards, Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 30 09:41:08 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Dec 2013 09:41:08 -0000 Subject: [Varnish] #1400: -S "" for varnishd is not working Message-ID: <044.9282743ec37c5826aad6cab27ca197aa@varnish-cache.org> #1400: -S "" for varnishd is not working --------------------+---------------------- Reporter: quiver | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | --------------------+---------------------- {{{ $ git show 909a1efbea8be8276e89dd8a1ceba28d87125c90 }}} says that > If you truly want no authentication of CLI connections, give an > empty -S argument (-S "") and live with the warning that causes. But if I specify -S "" for varnishd, I get error "Error: Cannot open -S file (''): No such file or directory" instead of "no CLI authentication" warning. varnish varsion : varnish-4.0.0-tp1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 30 10:02:34 2013 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Dec 2013 10:02:34 -0000 Subject: [Varnish] #1400: -S "" for varnishd is not working In-Reply-To: <044.9282743ec37c5826aad6cab27ca197aa@varnish-cache.org> References: <044.9282743ec37c5826aad6cab27ca197aa@varnish-cache.org> Message-ID: <059.5c38a732bf0691278d741e0a46fe45a1@varnish-cache.org> #1400: -S "" for varnishd is not working ----------------------+-------------------- Reporter: quiver | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by quiver): My fault. My init script was wrong. I get the expected behavior with the following command:: {{{ $ sudo /usr/local/sbin/varnishd -P /var/run/varnishd.pid -a :8080 -T localhost:6082 -f /usr/local/etc/varnish/default.vcl -p http_gzip_support=true -s file,80m -S "" Warning: Empty -S argument, no CLI authentication. }}} Please close this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From Uli.Staerk at globalways.net Thu Dec 12 13:20:23 2013 From: Uli.Staerk at globalways.net (=?iso-8859-1?Q?Uli_St=E4rk?=) Date: Thu, 12 Dec 2013 13:20:23 -0000 Subject: Varnish http format error Message-ID: Is there a limit regarding the cookie-count a response may contain? I got a http-format-error on a response containing 37 cookies :( Using Varnish 2.1 (Debian 6.0.8). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: varnishlog.txt URL: