From varnish-bugs at varnish-cache.org Mon Nov 2 10:23:08 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 10:23:08 -0000 Subject: [Varnish] #1813: Duplicate -a leads to assert instead of error message. Message-ID: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> #1813: Duplicate -a leads to assert instead of error message. ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Keywords: ----------------------+------------------- On 4.1.0, if you add the same -a twice, you get this error: {{{ varnish> root at lima:/etc/varnish# varnishadm panic.show Last panic at: Mon, 02 Nov 2015 10:20:15 GMT Assert error in vca_acct(), cache/cache_acceptor.c line 490: Condition((listen(ls->sock, cache_param->listen_depth)) == 0) not true. errno = 98 (Address already in use) thread = (cache-acceptor) version = varnish-4.1.0 revision 3041728 ident = Linux,3.16.0-4-amd64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433505: varnishd() [0x433505] 0x410f65: varnishd() [0x410f65] 0x7f78a92230a4: libpthread.so.0(+0x80a4) [0x7f78a92230a4] 0x7f78a8f5804d: libc.so.6(clone+0x6d) [0x7f78a8f5804d] }}} Child is continously being restarted. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 10:23:45 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 10:23:45 -0000 Subject: [Varnish] #1813: Duplicate -a leads to assert instead of error message. In-Reply-To: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> References: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> Message-ID: <061.df70ba8c48419abe7c1600cec7ecf2f1@varnish-cache.org> #1813: Duplicate -a leads to assert instead of error message. ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Description changed by lkarsten: Old description: > On 4.1.0, if you add the same -a twice, you get this error: > > {{{ > varnish> root at lima:/etc/varnish# varnishadm panic.show > Last panic at: Mon, 02 Nov 2015 10:20:15 GMT > Assert error in vca_acct(), cache/cache_acceptor.c line 490: > Condition((listen(ls->sock, cache_param->listen_depth)) == 0) not true. > errno = 98 (Address already in use) > thread = (cache-acceptor) > version = varnish-4.1.0 revision 3041728 > ident = > Linux,3.16.0-4-amd64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll > Backtrace: > 0x433505: varnishd() [0x433505] > 0x410f65: varnishd() [0x410f65] > 0x7f78a92230a4: libpthread.so.0(+0x80a4) [0x7f78a92230a4] > 0x7f78a8f5804d: libc.so.6(clone+0x6d) [0x7f78a8f5804d] > }}} > > Child is continously being restarted. New description: On 4.1.0, if you add the same -a twice, you get this error: {{{ varnish> root at lima:/etc/varnish# varnishadm panic.show Last panic at: Mon, 02 Nov 2015 10:20:15 GMT Assert error in vca_acct(), cache/cache_acceptor.c line 490: Condition((listen(ls->sock, cache_param->listen_depth)) == 0) not true. errno = 98 (Address already in use) thread = (cache-acceptor) version = varnish-4.1.0 revision 3041728 ident = Linux,3.16.0-4-amd64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433505: varnishd() [0x433505] 0x410f65: varnishd() [0x410f65] 0x7f78a92230a4: libpthread.so.0(+0x80a4) [0x7f78a92230a4] 0x7f78a8f5804d: libc.so.6(clone+0x6d) [0x7f78a8f5804d] }}} Child is continuously being restarted. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 10:29:09 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 10:29:09 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.0859c76fe7b25cc68ddda7a343a45e69@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by butzi): Yes, i can reproduce this. It makes no sense to me, when i handle the request with "return(pass)" instead of "return(pipe)" that it is not a varnish problem, right? The backends are not having the problems, when i access them without varnish. the client request: {{{ * << Request >> 380191421 - Begin req 380191413 rxreq - Timestamp Start: 1446459772.600275 0.000000 0.000000 - Timestamp Req: 1446459772.600275 0.000000 0.000000 - ReqStart 37.49.xxx.xxx 34154 - ReqMethod POST - ReqURL /index.php?cl=ecs_prudsys_recos_ajax - ReqProtocol HTTP/1.1 - ReqHeader Host: domain.tld - ReqHeader Connection: keep-alive - ReqHeader Content-Length: 97 - ReqHeader Accept: application/json, text/javascript, */*; q=0.01 - ReqHeader Origin: http://domain.tld - ReqHeader X-Requested-With: XMLHttpRequest - ReqHeader User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36 - ReqHeader Content-Type: application/x-www-form-urlencoded; charset=UTF-8 - ReqHeader Referer: http://domain.tld - ReqHeader Accept-Encoding: gzip, deflate - ReqHeader Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4 - ReqHeader Cookie: _ems_visitor=650367453.533136231; heias_0=a%3A2%3A%7Bi%3A0%3Bs%3A4%3A%22TRUE%22%3Bi%3A1%3Bi%3A1446458945%3B%7D; heias_sc=1; ctest2=1; SHOPDIRECT=none; sid_key=oxid; ecsadmatch=1; heias_pid=144645894528888948380; recoUser2session=0; language=3; re - ReqHeader X-Forwarded-For: 77.157.xxx.xxx - ReqHeader X-Real-IP: 77.157.xxx.xxx - ReqHeader X-CBR-IP: 77.157.xxx.xxx - ReqUnset X-Forwarded-For: 77.157.xxx.xxx - ReqHeader X-Forwarded-For: 77.157.xxx.xxx, 37.49.xxx.xxx - VCL_call RECV - ReqHeader X-UA-Device: Desktop - ReqHeader x-url: /index.php?cl=ecs_prudsys_recos_ajax - ReqHeader x-esi-level: 0 - VCL_return pipe - VCL_call HASH - ReqURL /index.php?cl=ecs_prudsys_recos_ajax - VCL_return lookup - Link bereq 380191422 pipe - Timestamp Pipe: 1446459772.600482 0.000207 0.000207 - Timestamp PipeSess: 1446459832.773508 60.173233 60.173026 - PipeAcct 1086 1200 97 7360 - End }}} the server request: {{{ * << BeReq >> 380191422 - Begin bereq 380191421 pipe - BereqMethod POST - BereqURL /index.php?cl=ecs_prudsys_recos_ajax - BereqProtocol HTTP/1.1 - BereqHeader Host: domain.tld - BereqHeader Connection: keep-alive - BereqHeader Content-Length: 97 - BereqHeader Accept: application/json, text/javascript, */*; q=0.01 - BereqHeader Origin: http://domain.tld - BereqHeader X-Requested-With: XMLHttpRequest - BereqHeader User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36 - BereqHeader Content-Type: application/x-www-form-urlencoded; charset=UTF-8 - BereqHeader Referer: http://domain.tld - BereqHeader Accept-Encoding: gzip, deflate - BereqHeader Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4 - BereqHeader Cookie: _ems_visitor=650367453.533136231; heias_0=a%3A2%3A%7Bi%3A0%3Bs%3A4%3A%22TRUE%22%3Bi%3A1%3Bi%3A1446458945%3B%7D; heias_sc=1; ctest2=1; SHOPDIRECT=none; sid_key=oxid; ecsadmatch=1; heias_pid=144645894528888948380; recoUser2session=0; language=3; re - BereqHeader X-Real-IP: 77.157.xxx.xxx - BereqHeader X-CBR-IP: 77.157.xxx.xxx - BereqHeader X-Forwarded-For: 77.157.xxx.xxx, 37.49.xxx.xxx - BereqHeader X-UA-Device: Desktop - BereqHeader x-url: /index.php?cl=ecs_prudsys_recos_ajax - BereqHeader x-esi-level: 0 - BereqHeader X-Varnish: 380191421 - BereqHeader Connection: close - VCL_call PIPE - BereqUnset Connection: keep-alive - BereqUnset Connection: close - BereqHeader connection: close - VCL_return pipe - BackendOpen 47 u1.prodas06 10.4.132.21 80 10.4.132.2 59156 - Timestamp Bereq: 1446459772.600479 0.000000 0.000000 - BackendClose 47 u1.prodas06 - BereqAcct 0 0 0 0 0 0 - End }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 10:35:09 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 10:35:09 -0000 Subject: [Varnish] #1813: Duplicate -a leads to assert instead of error message. In-Reply-To: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> References: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> Message-ID: <061.b3cff447673b71c80d7e3f2bad25cb22@varnish-cache.org> #1813: Duplicate -a leads to assert instead of error message. ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): {{{ [11:26:07] < phk> scn, re #1813 what kind of -a argument do you use that the arg-check doesn't catch it ? [11:26:16] < phk> critter phk> ./varnishd -a :8080 -a :8080 -d [11:26:16] < phk> Error: Cannot open socket: :8080: Address already in use [11:27:27] < scn> varnish 15719 1 1 11:22 ? 00:00:00 /usr/sbin/varnishd -a :80 -P /var/run/varnish.pid -f /etc/varnish/default.vcl -a :80 [11:28:05] < scn> at some point i added -a :80 before -P in the systemd service file [11:28:39] < scn> due to dropping of privs before/after writing the pidfile. i don't remember the details. [11:28:45] < phk> scn, this must be some linuxy thing that allows you to bind twice... [11:29:27] < scn> this line was from ps way up in my scrollback buffer, it would be longer. there is a PROXY listener as well. }}} todo: reproduce on linux. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 11:48:10 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 11:48:10 -0000 Subject: [Varnish] #1813: Duplicate -a leads to assert instead of error message. In-Reply-To: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> References: <046.bcb23ae46d49f69c5dfe8cfade75ca09@varnish-cache.org> Message-ID: <061.27ea88aec343b1cda3335421190a2d57@varnish-cache.org> #1813: Duplicate -a leads to assert instead of error message. ----------------------+---------------------------------------- Reporter: lkarsten | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [f861ad2174ffc85700c591fda0aadffe843d2ecf]: {{{ #!CommitTicketReference repository="" revision="f861ad2174ffc85700c591fda0aadffe843d2ecf" Fail if multiple -a arguments return the same suckaddr. Fixes #1813 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 12:25:55 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 12:25:55 -0000 Subject: [Varnish] #1805: Assert error in Tcheck() In-Reply-To: <043.acb5a31f440d7822afcc1e6804d74084@varnish-cache.org> References: <043.acb5a31f440d7822afcc1e6804d74084@varnish-cache.org> Message-ID: <058.ad99abd82399e5b4f7e6fd12fd37cf41@varnish-cache.org> #1805: Assert error in Tcheck() --------------------+---------------------------------- Reporter: colas | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: unknown Severity: normal | Resolution: worksforme Keywords: | --------------------+---------------------------------- Changes (by daghf): * status: reopened => closed * resolution: => worksforme Comment: The situation here looks to be that client has closed the connection when Varnish attempts to read the request body. This is not a Varnish bug. For further discussion, please use the varnish-misc mailing list for these inquiries. This is not a support forum. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 12:49:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 12:49:29 -0000 Subject: [Varnish] #1632: Debian: postinst broken In-Reply-To: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> References: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> Message-ID: <058.3afda01cbde452a0b04bb8fa620d4666@varnish-cache.org> #1632: Debian: postinst broken -----------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -----------------------+----------------------- Comment (by idl0r): The Upgrade to 4.1 worked fine so far. I guess this issue can be closed. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 13:49:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 13:49:36 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.6e52e5d7f3b4075b95857d82c05342e1@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by aondio): Hi, when you compiled the bug report you indicated 4.1 as the Varnish version you are using, but, the VCL you pasted seems a varnish 3.x VCL. That VCL wouldn't compile against V4.1, "sub vcl_fetch" is called "sub vcl_backend_fetch" starting from V4.0 and a "return(pipe)" is not allowed in that subroutine. Can you please give use the complete VCL you are using and the correct varnish version(varnishd -V)? Also, can you try to lower the pipe_timeout a little bit and check if the issue persists? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 14:17:13 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 14:17:13 -0000 Subject: [Varnish] #1632: Debian: postinst broken In-Reply-To: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> References: <043.bdb6966f18eda35af6376ddaeb977125@varnish-cache.org> Message-ID: <058.9fedb1cec8e0c8561554d3487165113b@varnish-cache.org> #1632: Debian: postinst broken -----------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: fixed Keywords: | -----------------------+----------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 15:27:12 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 15:27:12 -0000 Subject: [Varnish] #1805: Assert error in Tcheck() In-Reply-To: <043.acb5a31f440d7822afcc1e6804d74084@varnish-cache.org> References: <043.acb5a31f440d7822afcc1e6804d74084@varnish-cache.org> Message-ID: <058.443e5a2239aacc53ab0238f920fd5208@varnish-cache.org> #1805: Assert error in Tcheck() --------------------+---------------------------------- Reporter: colas | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: unknown Severity: normal | Resolution: worksforme Keywords: | --------------------+---------------------------------- Comment (by colas): Thank you for al advices. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 16:34:43 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 16:34:43 -0000 Subject: [Varnish] #1808: Error in Varnish Request Flox In-Reply-To: <043.713eddd679a70b3a60e6c677bb2bf1e3@varnish-cache.org> References: <043.713eddd679a70b3a60e6c677bb2bf1e3@varnish-cache.org> Message-ID: <058.78b92d592ee916642fc30e1132d58dbe@varnish-cache.org> #1808: Error in Varnish Request Flox --------------------+------------------------------ Reporter: colas | Owner: Type: defect | Status: closed Priority: high | Milestone: Varnish 4.0-TP2 Component: build | Version: trunk Severity: normal | Resolution: invalid Keywords: | --------------------+------------------------------ Comment (by francisco): We have improved the diagram in https://github.com/varnish/Varnish- Book/blob/master/ui/img/detailed_fsm.svg. VCL_hash_method is always called in vcl_recv. See line 701 in https://github.com/varnish/Varnish- Cache/blob/master/bin/varnishd/cache/cache_req_fsm.c#L701. There are cases where the hash key of a cached object is required regardless the next state. For example, the saintmode VMOD https://github.com/varnish/libvmod-saintmode uses the hash key of an object when maintaining the blacklist of sick backends. This list maps specific objects to specific backends. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 2 17:32:55 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 02 Nov 2015 17:32:55 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.8157849fb1a4772af0f7f510daf6ab18@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by butzi): Oh, my fault. vcl_recv was meant instead as vcl_fetch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 3 08:51:22 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 03 Nov 2015 08:51:22 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.386a99096632581cab3b4738055ffcf9@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by aondio): Hi, again, thanks for the answer. Can I also have the complete VCL you are using? Please, also try to "play" with the pipe_timeout as described in my previous comment. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 4 08:54:37 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 04 Nov 2015 08:54:37 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.25cad28c1d0771fd44248737b3f1efdc@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by butzi): Hi, sorry the complete vcl is not possible. In front of the posted part above is only a part where different backends are choosen in conditions, which are not met be the request with the problem. I did not changed the pipe_timeout until now, so it is on 60s by default. Changing this to a lower value could become a problem. As far as i could find some infos to this value, it should be the same value as first_byte_timeout or longer, but not shorter. I will take look if there is a way to test the timeout and the other ones with 60s default, but this will take some time. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 4 09:03:45 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 04 Nov 2015 09:03:45 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.3a15e8082743a2217d9519a5804a455f@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by aondio): Hi, I've created a test case which tries to reproduce this issue, in the test case I've used the above VCL, so far I haven't been able to make that test case fail as in you case, this is why I need the your real VCL. If I can't get access to the complete VCL, I would also appreciate only part of it, such as the complete vcl_recv and the complete vcl_pipe. If you don't want to post it here, you can send it to arianna.aondio at varnish- software.com -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 4 12:55:22 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 04 Nov 2015 12:55:22 -0000 Subject: [Varnish] #1801: Fail parsing IPv6 constants In-Reply-To: <043.f269ea63a9a5a2c445c8af43e75b18dd@varnish-cache.org> References: <043.f269ea63a9a5a2c445c8af43e75b18dd@varnish-cache.org> Message-ID: <058.e8ebc2c7080c8b0ccccd2ef2e276016f@varnish-cache.org> #1801: Fail parsing IPv6 constants ----------------------+--------------------------------------------- Reporter: fgsch | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * owner: => Federico G. Schwindt * status: reopened => closed * resolution: => fixed Comment: In [a8067c730a180a1d044bce73ad87fc25a0f4995b]: {{{ #!CommitTicketReference repository="" revision="a8067c730a180a1d044bce73ad87fc25a0f4995b" Relax IP constant parsing Fixes #1801. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 4 17:14:13 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 04 Nov 2015 17:14:13 -0000 Subject: [Varnish] #1793: Assert error in default_oc_getobj() In-Reply-To: <045.597d8a2e6b21666e8f19cff1d3e7a950@varnish-cache.org> References: <045.597d8a2e6b21666e8f19cff1d3e7a950@varnish-cache.org> Message-ID: <060.d4cf8301a42a647e18b56fc275e676bf@varnish-cache.org> #1793: Assert error in default_oc_getobj() --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: assert error | --------------------------+------------------------ Comment (by fgsch): Similar to #1670. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 9 09:12:50 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Nov 2015 09:12:50 -0000 Subject: [Varnish] #1807: Assert error in cnt_deliver() In-Reply-To: <045.c846bac4413e89d548cb34e49709b1fd@varnish-cache.org> References: <045.c846bac4413e89d548cb34e49709b1fd@varnish-cache.org> Message-ID: <060.f198957c8ba3664f96b1e48bdd69c89c@varnish-cache.org> #1807: Assert error in cnt_deliver() --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: Assert error | --------------------------+------------------------ Comment (by phk): Did you by any chance decrease the http_max_hdr parameter while running ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 9 09:15:51 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Nov 2015 09:15:51 -0000 Subject: [Varnish] #1807: Assert error in cnt_deliver() In-Reply-To: <045.c846bac4413e89d548cb34e49709b1fd@varnish-cache.org> References: <045.c846bac4413e89d548cb34e49709b1fd@varnish-cache.org> Message-ID: <060.725b12c76003a53902be03bc758d195d@varnish-cache.org> #1807: Assert error in cnt_deliver() --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: Assert error | --------------------------+------------------------ Comment (by llavaud): no i never touch this one but i have this parameters for startup: {{{ NFILES=262144 MEMLOCK=164000 DAEMON_OPTS="-a :80 \ -T 0.0.0.0:6083 \ -S /etc/varnish/secret \ -f /etc/varnish/varnish.vcl \ -p thread_pool_max=5000 \ -p thread_pool_min=1300 \ -p feature=+esi_disable_xml_check \ -p http_req_hdr_len=16k \ -p http_resp_hdr_len=16k \ -p workspace_backend=256k \ -p workspace_client=256k \ -p workspace_session=768 \ -p workspace_thread=4k \ -l 160m \ -s file,/srv/faststorage/varnish/storage.bin,100G" -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 9 09:46:23 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Nov 2015 09:46:23 -0000 Subject: [Varnish] #1807: Assert error in cnt_deliver() In-Reply-To: <045.c846bac4413e89d548cb34e49709b1fd@varnish-cache.org> References: <045.c846bac4413e89d548cb34e49709b1fd@varnish-cache.org> Message-ID: <060.e0c32ab3f656c505ab835038cfbe91d2@varnish-cache.org> #1807: Assert error in cnt_deliver() --------------------------+---------------------------------------- Reporter: llavaud | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: fixed Keywords: Assert error | --------------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [91755a001a9691b3ce12c20ea1402164685c7ed9]: {{{ #!CommitTicketReference repository="" revision="91755a001a9691b3ce12c20ea1402164685c7ed9" Return 500 if we cannot decode the stored object into the resp.* This can happen in a number of obscure corner-cases, which do not warrant a panic. Fixes: #1807 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 9 10:32:21 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Nov 2015 10:32:21 -0000 Subject: [Varnish] #1795: Man page issues in 4.1 In-Reply-To: <043.3248b86a133da7a2e2f3f47447587d62@varnish-cache.org> References: <043.3248b86a133da7a2e2f3f47447587d62@varnish-cache.org> Message-ID: <058.37249eef62a4efc7e79956b9376cd386@varnish-cache.org> #1795: Man page issues in 4.1 ---------------------------+--------------------------------------------- Reporter: Dridi | Owner: Federico G. Schwindt Type: documentation | Status: closed Priority: normal | Milestone: Component: documentation | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ---------------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * owner: => Federico G. Schwindt * status: new => closed * resolution: => fixed Comment: In [d1fdd6b4fe764789fa35c472858278eee17437f3]: {{{ #!CommitTicketReference repository="" revision="d1fdd6b4fe764789fa35c472858278eee17437f3" Add copyright notice and date where missing Also sort see also correctly. Fix #1795 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 9 13:14:03 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Nov 2015 13:14:03 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.37ccaa9f7e1f058e7bd7683a12d2f006@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------- Reporter: geoff | Owner: geoff Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Changes (by martin): * status: closed => reopened * resolution: fixed => Comment: Reopened as a reminder to apply this to 4.0 maintenance branch. The current patch looks like it misses a test case. Geoff: Could you provide a test case and push to 4.0? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 9 13:16:20 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Nov 2015 13:16:20 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.025be96c53607329c37305a2172a3265@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------- Reporter: geoff | Owner: geoff Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by lkarsten): original msg id to -dev: <561AAB12.3000402 at uplex.de> -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 9 13:43:07 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 09 Nov 2015 13:43:07 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.929938211d57b7d70c35d059bb053967@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------- Reporter: geoff | Owner: geoff Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by geoff): Unfortunately I don't have a test case, because we never discovered how to reliably reproduce the problem. So I couldn't create a vtc that would fail unless the patch is applied. I'm confident that the patch resolves the problem, because it never happened again after we applied it in production. FWIW, the patch is a one-liner: set the wantbody flag to 0 when the response code was 204 (previously done only when the response is 304) -- this is one of the things that happens in phk's patch for what is now 4.1. For the reasons described in the second comment, I think this has to be the solution. But I'm afraid I can't prove it with a vtc, only from our experience of a bug being there and then going away. @martin, what should we do? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 10 10:54:11 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 10 Nov 2015 10:54:11 -0000 Subject: [Varnish] #1635: Completed bans keep accumulating In-Reply-To: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> References: <043.d9a46f331b8fae5fc5502a3059307d4c@varnish-cache.org> Message-ID: <058.5b903e0d15332d67cd2d13b8ce6978d2@varnish-cache.org> #1635: Completed bans keep accumulating ----------------------+---------------------------------------- Reporter: Sesse | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: lurker | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [91d77ac75fba9e8240966ce3e52771118e92b3a0]: {{{ #!CommitTicketReference repository="" revision="91d77ac75fba9e8240966ce3e52771118e92b3a0" Modify the ban_lurker so we lift oc's as far up the ban-list as we can when we check a batch of lurkable bans. For obj.* only bans, this should concentrate the entire list at the very top. If there are req.* bans, the oc's end up on the bans right below the req.* bans. Fixes #1635 (As much as we can fix it) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 11 05:09:23 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Nov 2015 05:09:23 -0000 Subject: [Varnish] #1814: Documentation Bug Message-ID: <047.e42befd26cdc4382001f7fb34341f1e0@varnish-cache.org> #1814: Documentation Bug ---------------------------------------+--------------------------- Reporter: pprocacci | Type: defect Status: new | Priority: lowest Milestone: Varnish 4.1-TP1 | Component: documentation Version: 4.1.0 | Severity: trivial Keywords: Documentation Doc Grammer | ---------------------------------------+--------------------------- vcl(7) has the following line of text: "Note that are no loops or iterators of any kind in VCL." I imagine this should read: "Note that there are no loops or iterators of any kind in VCL." -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 11 09:21:23 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Nov 2015 09:21:23 -0000 Subject: [Varnish] #1815: Child died on pipe request Message-ID: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> #1815: Child died on pipe request -------------------------+---------------------- Reporter: jferjan | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.3 | Severity: major Keywords: pipe, panic | -------------------------+---------------------- Child died on pipe request. It is possible that backend was not properly responding or was unreachable at that time. Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) not responding to CLI, killing it. Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) not responding to CLI, killing it. Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) died signal=6 Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) Panic message: Assert error in VDI_GetFd(), cache/cache_dir.c line 111: Condition((d) != NULL) not true. thread = (cache-worker) version = varnish-4.0.3 revision b8c4a34 ident = Linux,3.10.0-229.4.2.el7.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433dbd: /usr/sbin/varnishd() [0x433dbd] 0x418915: /usr/sbin/varnishd(VDI_GetFd+0xc5) [0x418915] 0x434855: /usr/sbin/varnishd(PipeRequest+0xc5) [0x434855] 0x4384f1: /usr/sbin/varnishd(CNT_Request+0xac1) [0x4384f1] 0x42e14b: /usr/sbin/varnishd(HTTP1_Session+0x7ab) [0x42e14b] 0x43c2c7: /usr/sbin/varnishd() [0x43c2c7] 0x43d228: /usr/sbin/varnishd(SES_pool_accept_task+0x2a8) [0x43d228] 0x436c82: /usr/sbin/varnishd(Pool_Work_Thread+0x392) [0x436c82] 0x449dbc: /usr/sbin/varnishd() [0x449dbc] 0x7f42aa319df5: /lib64/libpthread.so.0(+0x7df5) [0x7f42aa319df5] req = 0x7f38ebde6020 { sp = 0x7f393bca3d60, vxid = 1150288528, step = R_STP_PIPE, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7f393bca3d60 { fd = 167, vxid = 76546703, client = 193.24.248.30 8902, step = S_STP_WORKING, }, worker = 0x7f36cd5f2c50 { ws = 0x7f36cd5f2e70 { id = "wrk", {s,f,r,e} = {0x7f36cd5f2450,0x7f36cd5f2450,(nil),+2048}, }, VCL::method = 0x0, VCL::return = pipe, }, ws = 0x7f38ebde61b8 { id = "req", {s,f,r,e} = {0x7f38ebde8010,+344,(nil),+57360}, }, http[req] = { ws = 0x7f38ebde61b8[req] "PROPFIND", "/fileadmin/pageuploads/foo", "HTTP/1.1", "Via: 1.1 TMG2-SI", "User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601", "Host: www.example.com", "Depth: 0", "translate: f", "Connection: Keep-Alive", "Content-Length: 0", "X-Forwarded-For: 123.123.123.123", }, vcl = { srcname = { "input", "Builtin", }, }, }, Nov 10 14:49:51 varnish4 varnishd[25760]: child (25732) Started Nov 10 14:49:51 varnish4 varnishd[25760]: Child (25732) said Child starts possible duplicate: https://www.varnish-cache.org/trac/ticket/1730 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 11 09:42:24 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Nov 2015 09:42:24 -0000 Subject: [Varnish] #1815: Child died on pipe request In-Reply-To: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> References: <045.fd9ff74855f45ed16026a18196ea076c@varnish-cache.org> Message-ID: <060.c9a35f53203c1d6768fbfe26946eb6c1@varnish-cache.org> #1815: Child died on pipe request -------------------------+-------------------- Reporter: jferjan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: major | Resolution: Keywords: pipe, panic | -------------------------+-------------------- Description changed by phk: Old description: > Child died on pipe request. It is possible that backend was not properly > responding or was unreachable at that time. > > Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) not responding to > CLI, killing it. > Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) not responding to > CLI, killing it. > Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) died signal=6 > Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) Panic message: > Assert error in VDI_GetFd(), cache/cache_dir.c line 111: > Condition((d) != NULL) not true. > thread = (cache-worker) > version = varnish-4.0.3 revision b8c4a34 > ident = > Linux,3.10.0-229.4.2.el7.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll > Backtrace: > 0x433dbd: /usr/sbin/varnishd() [0x433dbd] > 0x418915: /usr/sbin/varnishd(VDI_GetFd+0xc5) [0x418915] > 0x434855: /usr/sbin/varnishd(PipeRequest+0xc5) [0x434855] > 0x4384f1: /usr/sbin/varnishd(CNT_Request+0xac1) [0x4384f1] > 0x42e14b: /usr/sbin/varnishd(HTTP1_Session+0x7ab) [0x42e14b] > 0x43c2c7: /usr/sbin/varnishd() [0x43c2c7] > 0x43d228: /usr/sbin/varnishd(SES_pool_accept_task+0x2a8) [0x43d228] > 0x436c82: /usr/sbin/varnishd(Pool_Work_Thread+0x392) [0x436c82] > 0x449dbc: /usr/sbin/varnishd() [0x449dbc] > 0x7f42aa319df5: /lib64/libpthread.so.0(+0x7df5) [0x7f42aa319df5] > req = 0x7f38ebde6020 { > sp = 0x7f393bca3d60, vxid = 1150288528, step = R_STP_PIPE, > req_body = R_BODY_NONE, > restarts = 0, esi_level = 0, > sp = 0x7f393bca3d60 { > fd = 167, vxid = 76546703, > client = 193.24.248.30 8902, > step = S_STP_WORKING, > }, > worker = 0x7f36cd5f2c50 { > ws = 0x7f36cd5f2e70 { > id = "wrk", > {s,f,r,e} = {0x7f36cd5f2450,0x7f36cd5f2450,(nil),+2048}, > }, > VCL::method = 0x0, > VCL::return = pipe, > }, > ws = 0x7f38ebde61b8 { > id = "req", > {s,f,r,e} = {0x7f38ebde8010,+344,(nil),+57360}, > }, > http[req] = { > ws = 0x7f38ebde61b8[req] > "PROPFIND", > "/fileadmin/pageuploads/foo", > "HTTP/1.1", > "Via: 1.1 TMG2-SI", > "User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601", > "Host: www.example.com", > "Depth: 0", > "translate: f", > "Connection: Keep-Alive", > "Content-Length: 0", > "X-Forwarded-For: 123.123.123.123", > }, > vcl = { > srcname = { > "input", > "Builtin", > }, > }, > }, > Nov 10 14:49:51 varnish4 varnishd[25760]: child (25732) Started > Nov 10 14:49:51 varnish4 varnishd[25760]: Child (25732) said Child starts > > possible duplicate: https://www.varnish-cache.org/trac/ticket/1730 New description: Child died on pipe request. It is possible that backend was not properly responding or was unreachable at that time. {{{ Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) not responding to CLI, killing it. Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) not responding to CLI, killing it. Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) died signal=6 Nov 10 14:49:51 varnish4 varnishd[25760]: Child (30586) Panic message: Assert error in VDI_GetFd(), cache/cache_dir.c line 111: Condition((d) != NULL) not true. thread = (cache-worker) version = varnish-4.0.3 revision b8c4a34 ident = Linux,3.10.0-229.4.2.el7.x86_64,x86_64,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x433dbd: /usr/sbin/varnishd() [0x433dbd] 0x418915: /usr/sbin/varnishd(VDI_GetFd+0xc5) [0x418915] 0x434855: /usr/sbin/varnishd(PipeRequest+0xc5) [0x434855] 0x4384f1: /usr/sbin/varnishd(CNT_Request+0xac1) [0x4384f1] 0x42e14b: /usr/sbin/varnishd(HTTP1_Session+0x7ab) [0x42e14b] 0x43c2c7: /usr/sbin/varnishd() [0x43c2c7] 0x43d228: /usr/sbin/varnishd(SES_pool_accept_task+0x2a8) [0x43d228] 0x436c82: /usr/sbin/varnishd(Pool_Work_Thread+0x392) [0x436c82] 0x449dbc: /usr/sbin/varnishd() [0x449dbc] 0x7f42aa319df5: /lib64/libpthread.so.0(+0x7df5) [0x7f42aa319df5] req = 0x7f38ebde6020 { sp = 0x7f393bca3d60, vxid = 1150288528, step = R_STP_PIPE, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7f393bca3d60 { fd = 167, vxid = 76546703, client = 193.24.248.30 8902, step = S_STP_WORKING, }, worker = 0x7f36cd5f2c50 { ws = 0x7f36cd5f2e70 { id = "wrk", {s,f,r,e} = {0x7f36cd5f2450,0x7f36cd5f2450,(nil),+2048}, }, VCL::method = 0x0, VCL::return = pipe, }, ws = 0x7f38ebde61b8 { id = "req", {s,f,r,e} = {0x7f38ebde8010,+344,(nil),+57360}, }, http[req] = { ws = 0x7f38ebde61b8[req] "PROPFIND", "/fileadmin/pageuploads/foo", "HTTP/1.1", "Via: 1.1 TMG2-SI", "User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601", "Host: www.example.com", "Depth: 0", "translate: f", "Connection: Keep-Alive", "Content-Length: 0", "X-Forwarded-For: 123.123.123.123", }, vcl = { srcname = { "input", "Builtin", }, }, }, Nov 10 14:49:51 varnish4 varnishd[25760]: child (25732) Started Nov 10 14:49:51 varnish4 varnishd[25760]: Child (25732) said Child starts }}} possible duplicate: https://www.varnish-cache.org/trac/ticket/1730 -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 11 09:48:07 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Nov 2015 09:48:07 -0000 Subject: [Varnish] #1659: ban lurker doesn't purge all effected objects In-Reply-To: <059.d0008c342b62ce4e6a704e0084bc4f28@varnish-cache.org> References: <059.d0008c342b62ce4e6a704e0084bc4f28@varnish-cache.org> Message-ID: <074.bc16702466cdb088c340aeee42c08c8b@varnish-cache.org> #1659: ban lurker doesn't purge all effected objects -----------------------+------------------------- Reporter: varnish@? | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.6 Severity: normal | Resolution: worksforme Keywords: | -----------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I'm timing this ticket out. We have done significant work on the ban-lurker since then and there is a very good chance that this issue has been fixed by them. Please open a new ticket if this still happens in 4.1.x -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 11 09:54:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Nov 2015 09:54:29 -0000 Subject: [Varnish] #1734: segfault after vcl.state cold In-Reply-To: <055.ec7692e32d951e1b1e281c27d6c75658@varnish-cache.org> References: <055.ec7692e32d951e1b1e281c27d6c75658@varnish-cache.org> Message-ID: <070.df4872aabf9520602de55fb4d8ac7c2a@varnish-cache.org> #1734: segfault after vcl.state cold ---------------------------------+---------------------------------- Reporter: zaterio@? | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: vcl state cold warm | ---------------------------------+---------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: timed out -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 11 10:18:01 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Nov 2015 10:18:01 -0000 Subject: [Varnish] #1661: Assert error in VRY_Validate(), cache/cache_vary.c line 377 In-Reply-To: <050.a0d7a51674fccc155f59afe0a5199aa8@varnish-cache.org> References: <050.a0d7a51674fccc155f59afe0a5199aa8@varnish-cache.org> Message-ID: <065.f71da29a321fe64b7f769f218010b581@varnish-cache.org> #1661: Assert error in VRY_Validate(), cache/cache_vary.c line 377 --------------------------+---------------------- Reporter: mattrobenolt | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: unknown Severity: major | Resolution: fixed Keywords: vary, panic | --------------------------+---------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: This looks like it boils down to workspace exhaustion. Some patches were added to make it clearer that that is what happened. Not seen evidence of this assertion happening again, so closing the bug. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 11 23:50:40 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 11 Nov 2015 23:50:40 -0000 Subject: [Varnish] #1814: Documentation Bug In-Reply-To: <047.e42befd26cdc4382001f7fb34341f1e0@varnish-cache.org> References: <047.e42befd26cdc4382001f7fb34341f1e0@varnish-cache.org> Message-ID: <062.abf9ccbb00de6c484f92578fa5cf5569@varnish-cache.org> #1814: Documentation Bug -------------------------------------+------------------------------------- Reporter: pprocacci | Owner: Federico G. Schwindt Type: defect | Priority: lowest | Status: closed Component: documentation | Milestone: Varnish 4.1-TP1 Severity: trivial | Version: 4.1.0 Keywords: Documentation Doc | Resolution: fixed Grammer | -------------------------------------+------------------------------------- Changes (by Federico G. Schwindt ): * owner: => Federico G. Schwindt * status: new => closed * resolution: => fixed Comment: In [f540a812b267fabb4a1d305db2e271fd613e4a7a]: {{{ #!CommitTicketReference repository="" revision="f540a812b267fabb4a1d305db2e271fd613e4a7a" Typos and grammar Fixes #1814 and more. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 12 13:55:38 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Nov 2015 13:55:38 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.fe96275fed143d79af382aad6c5c6f61@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by butzi): I send you the VCL via Mail. I also send you some details, how you could reproduce this on our live setup. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 12 16:48:27 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 12 Nov 2015 16:48:27 -0000 Subject: [Varnish] #1816: Return 304 for If-None-Match on weak ETag match (cache hit) Message-ID: <048.42c9cb84005dbc900bc1c04d266402c4@varnish-cache.org> #1816: Return 304 for If-None-Match on weak ETag match (cache hit) ---------------------------------------------+---------------------- Reporter: teohhanhui | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.3 | Severity: normal Keywords: 304 if-none-match weak etag hit | ---------------------------------------------+---------------------- Currently when the client sends a request with weak ETag and it matches, Varnish returns response with 200 status code on cache hit. But it should actually return 304 just like with strong ETag. See https://tools.ietf.org/html/rfc7232#section-3.2 > 3.2. If-None-Match > A recipient MUST use the weak comparison function when comparing entity- tags for If-None-Match (Section 2.3.2), since weak entity-tags can be used for cache validation even if there have been changes to the representation data. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 12:22:07 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 12:22:07 -0000 Subject: [Varnish] #1731: 4.0.3 Panic In-Reply-To: <047.eff33cac2cd7895995bd2969faac6b35@varnish-cache.org> References: <047.eff33cac2cd7895995bd2969faac6b35@varnish-cache.org> Message-ID: <062.d3f90b639e621a7d3de326f5faf9092a@varnish-cache.org> #1731: 4.0.3 Panic -----------------------+---------------------------------- Reporter: billnbell | Owner: Type: defect | Status: closed Priority: highest | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: worksforme Keywords: | -----------------------+---------------------------------- Changes (by martin): * status: new => closed * resolution: => worksforme Comment: This is workspace exhaustion. Original advise stands. Reclosing. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 12:23:26 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 12:23:26 -0000 Subject: [Varnish] #1723: High CPU load and exponential peak of objects in a281a10 In-Reply-To: <055.a2a864aec40e58c05df529f7335d48da@varnish-cache.org> References: <055.a2a864aec40e58c05df529f7335d48da@varnish-cache.org> Message-ID: <070.63ff99906e1dadffb5a3b89ddbeaecf3@varnish-cache.org> #1723: High CPU load and exponential peak of objects in a281a10 --------------------------+---------------------------------- Reporter: zaterio@? | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: major | Resolution: worksforme Keywords: load objects | --------------------------+---------------------------------- Changes (by daghf): * status: new => closed * resolution: => worksforme Comment: timed out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 12:25:17 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 12:25:17 -0000 Subject: [Varnish] #1738: Large number of ExpKills and nuking issues In-Reply-To: <046.466e6bbaa373aa0943f5cd40ca1553a1@varnish-cache.org> References: <046.466e6bbaa373aa0943f5cd40ca1553a1@varnish-cache.org> Message-ID: <061.3fe149f25a18b517e8fc3288df015350@varnish-cache.org> #1738: Large number of ExpKills and nuking issues ----------------------+------------------------- Reporter: coredump | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by daghf): * status: new => closed * resolution: => worksforme Comment: timed out. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 12:25:48 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 12:25:48 -0000 Subject: [Varnish] #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: In-Reply-To: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> References: <043.f71a854c635b7ea5de5ec292dbcbe25b@varnish-cache.org> Message-ID: <058.f9bdd3a5b45c82b24c168bc99bb2a4e5@varnish-cache.org> #1739: overflow on "o ws - Assert error in VFP_Push(), cache/cache_fetch_proc.c line 200: ----------------------+---------------------- Reporter: slink | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: invalid Keywords: | ----------------------+---------------------- Changes (by slink): * status: new => closed * resolution: => invalid Comment: would need to be reproduced on current master -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 12:37:12 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 12:37:12 -0000 Subject: [Varnish] #1753: Bakend flapping and High load In-Reply-To: <055.c248038e6b81e813234f043d436513ed@varnish-cache.org> References: <055.c248038e6b81e813234f043d436513ed@varnish-cache.org> Message-ID: <070.8c130ce0a3f244adfc81a7e8bb3a1a43@varnish-cache.org> #1753: Bakend flapping and High load -----------------------+---------------------------------- Reporter: zaterio@? | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------- Changes (by slink): * status: new => needinfo Comment: irc: please try master and get back if still an issue -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 12:42:07 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 12:42:07 -0000 Subject: [Varnish] #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 In-Reply-To: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> References: <043.4c8744d010240f820f7b2440cfafa2fc@varnish-cache.org> Message-ID: <058.0419514071406c9a5dfed6ca46f14856@varnish-cache.org> #1761: 204 responses intermittently delivered as chunk-encoded with length byte = 0 ----------------------+---------------------------------- Reporter: geoff | Owner: geoff Type: defect | Status: reopened Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ----------------------+---------------------------------- Comment (by geoff): martin and I agreed in bugwash that we'll push the patch to the 4.0 branch and close. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 12:42:27 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 12:42:27 -0000 Subject: [Varnish] #1762: VSL API: endless loop and out of memory in vtx_scan() on forced synthetic transactions In-Reply-To: <043.7e4033f2b41b2a9ac26a953b52c4e27d@varnish-cache.org> References: <043.7e4033f2b41b2a9ac26a953b52c4e27d@varnish-cache.org> Message-ID: <058.e67878265c7c8c254dc5886a8223678b@varnish-cache.org> #1762: VSL API: endless loop and out of memory in vtx_scan() on forced synthetic transactions ----------------------+---------------------------------- Reporter: geoff | Owner: slink Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: 4.0.3 Severity: critical | Resolution: fixed Keywords: | ----------------------+---------------------------------- Changes (by slink): * status: assigned => closed * resolution: => fixed Comment: agreed with geoff that this is solved for real -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 18:38:45 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 18:38:45 -0000 Subject: [Varnish] #1734: segfault after vcl.state cold In-Reply-To: <055.ec7692e32d951e1b1e281c27d6c75658@varnish-cache.org> References: <055.ec7692e32d951e1b1e281c27d6c75658@varnish-cache.org> Message-ID: <070.6af234c0e2556e7f10ec353d413ff240@varnish-cache.org> #1734: segfault after vcl.state cold ---------------------------------+---------------------------------- Reporter: zaterio@? | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: vcl state cold warm | ---------------------------------+---------------------------------- Comment (by zaterio@?): I can confirm is fixed (test in 5d099e9) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 16 18:55:39 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 16 Nov 2015 18:55:39 -0000 Subject: [Varnish] #1753: Bakend flapping and High load In-Reply-To: <055.c248038e6b81e813234f043d436513ed@varnish-cache.org> References: <055.c248038e6b81e813234f043d436513ed@varnish-cache.org> Message-ID: <070.35318e25c636a9631c7a29619990146e@varnish-cache.org> #1753: Bakend flapping and High load -----------------------+---------------------------------- Reporter: zaterio@? | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------- Comment (by zaterio@?): I can confirm is fixed , tested on the same server, same traffic and load. {{{ varnishd -V varnishd (varnish-trunk revision 5d099e9) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2015 Varnish Software AS }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 17 09:51:11 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Nov 2015 09:51:11 -0000 Subject: [Varnish] #1753: Bakend flapping and High load In-Reply-To: <055.c248038e6b81e813234f043d436513ed@varnish-cache.org> References: <055.c248038e6b81e813234f043d436513ed@varnish-cache.org> Message-ID: <070.a72aded67cd6cd864e3b1a6512c4679c@varnish-cache.org> #1753: Bakend flapping and High load -----------------------+---------------------------------- Reporter: zaterio@? | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.0 release Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -----------------------+---------------------------------- Changes (by slink): * status: needinfo => closed * resolution: => fixed Comment: thanks -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 17 21:26:41 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 17 Nov 2015 21:26:41 -0000 Subject: [Varnish] #1817: Support SDCH Compression Message-ID: <044.fa8ada094971aea44ba4f417383d4488@varnish-cache.org> #1817: Support SDCH Compression ---------------------+------------------------- Reporter: adamzr | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: unknown | Severity: normal Keywords: | ---------------------+------------------------- Google has created an alternative to GZIP compression called SDCH. This is a feature request to support Varnish using this format as a GZIP alternative. Varnish would have to periodically build a dictionary for the content it has in the cache. I think this could result in a significant reduction in the data sent to clients. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 18 11:51:22 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Nov 2015 11:51:22 -0000 Subject: [Varnish] #1817: Support SDCH Compression In-Reply-To: <044.fa8ada094971aea44ba4f417383d4488@varnish-cache.org> References: <044.fa8ada094971aea44ba4f417383d4488@varnish-cache.org> Message-ID: <059.ee94128877daacbdfb8a49581ee85cc7@varnish-cache.org> #1817: Support SDCH Compression -------------------------+---------------------- Reporter: adamzr | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: invalid Keywords: | -------------------------+---------------------- Changes (by lkarsten): * status: new => closed * resolution: => invalid Comment: Hi. The Varnish bug tracker is only used for actionable bugs. Please file feature requests in the wiki: https://www.varnish-cache.org/trac/wiki/Future_Feature -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 18 11:59:45 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Nov 2015 11:59:45 -0000 Subject: [Varnish] #1818: Grace does not work for hit-for-pass objects Message-ID: <043.cc2bc4a259a4448c6bd3b40b0d202ef4@varnish-cache.org> #1818: Grace does not work for hit-for-pass objects ----------------------+------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- Objcores marked as hit-for-pass (OC_F_PASS flag) are not considered for grace mode. Grace is quite useful also for hit-for-pass, as it would let us avoid waitlisting of requests after a HFP object goes stale. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 18 12:04:04 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 18 Nov 2015 12:04:04 -0000 Subject: [Varnish] #1818: Grace does not work for hit-for-pass objects In-Reply-To: <043.cc2bc4a259a4448c6bd3b40b0d202ef4@varnish-cache.org> References: <043.cc2bc4a259a4448c6bd3b40b0d202ef4@varnish-cache.org> Message-ID: <058.6e0cea9b7d7f636ba97ff26d581d7b05@varnish-cache.org> #1818: Grace does not work for hit-for-pass objects ----------------------+-------------------- Reporter: daghf | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by daghf): Test case. The request from client c2 ends up being waitlisted, and thus ends up in a deadlock situation. {{{ varnishtest "#1818: verify that grace works for hit_for_pass objects" server s1 { rxreq expect req.http.a == "1" txresp rxreq expect req.http.b == "1" sema r2 sync 2 sema r1 sync 2 txresp } -start server s2 { rxreq expect req.http.c == "1" sema r1 sync 2 txresp } -start varnish v1 -vcl+backend { sub vcl_recv { if (req.http.c) { set req.backend_hint = s2; } } sub vcl_miss { set req.http.miss = "1"; } sub vcl_pass { set req.http.pass = "1"; } sub vcl_deliver { if (req.http.miss) { set resp.http.miss = req.http.miss; } if (req.http.pass) { set resp.http.pass = req.http.pass; } } sub vcl_backend_response { set beresp.ttl = 0.1s; set beresp.grace = 1m; set beresp.uncacheable = true; } } -start client c1 { txreq -hdr "a: 1" rxresp delay .2 txreq -hdr "b: 1" rxresp expect resp.http.miss == "1" } -start client c2 { sema r2 sync 2 txreq -hdr "c: 1" rxresp expect resp.http.pass == "1" } -run }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 19 08:51:19 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Nov 2015 08:51:19 -0000 Subject: [Varnish] #1785: r01576.vtc fails on jessie armv7l. In-Reply-To: <046.3796e0bf19bc6694851715fe36fe2682@varnish-cache.org> References: <046.3796e0bf19bc6694851715fe36fe2682@varnish-cache.org> Message-ID: <061.817182dd0438e726cf3fe9a354123ad7@varnish-cache.org> #1785: r01576.vtc fails on jessie armv7l. ----------------------+------------------------- Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: worksforme Keywords: | ----------------------+------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This test-case has been disabled. It is too hard to keep it working across all platforms/PCRE versions. If you need recursive regexp's you're probably doing it wrong anyway. (https://twitter.com/felixkronlage/status/667010723369885698) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 19 23:39:21 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 19 Nov 2015 23:39:21 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.aea99fda472cfad515d6b4a5234bcde3@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by Hilaus): I have the same problem. Did you resolve it? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 20 08:08:55 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Nov 2015 08:08:55 -0000 Subject: [Varnish] #1819: Can't access documentation of cookie Message-ID: <043.16838e456817cf67d6dbb2acbc693e91@varnish-cache.org> #1819: Can't access documentation of cookie -----------------------------+-------------------- Reporter: colas | Type: defect Status: new | Priority: normal Milestone: Varnish 4.1-TP1 | Component: build Version: 4.1.0 | Severity: normal Keywords: | -----------------------------+-------------------- Hello, From this page https://www.varnish-cache.org/docs/4.1/users- guide/performance.html#users-performance I can't access to the part of Cookies. I'm redirect to this page for exemple https://www.varnish- cache.org/docs/4.1/users-guide/increasing-your-hitrate.html#cookies but it's not the good one. Thanks for help. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 20 08:59:49 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Nov 2015 08:59:49 -0000 Subject: [Varnish] #1820: Assert error in SES_Delete Message-ID: <045.e76209f816c7781b0f5ad7c7524e235d@varnish-cache.org> #1820: Assert error in SES_Delete --------------------------+---------------------- Reporter: llavaud | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.1.0-TP1 | Severity: normal Keywords: assert error | --------------------------+---------------------- {{{ webcache20:~# varnishadm panic.show Last panic at: Tue, 17 Nov 2015 13:21:47 GMT Assert error in SES_Delete(), cache/cache_session.c line 575: Condition(now >= sp->t_open) not true. thread = (cache-worker) version = varnish-4.1.0-tp1 revision 0e4e1bc ident = Linux,3.2.0-4-amd64,x86_64,-junix,-sfile,-smalloc,-hcritbit,epoll Backtrace: 0x4343a4: pan_ic+0x134 0x43bde0: ses_handle 0x44f2c3: HTTP1_Session+0x853 0x43a841: SES_Proto_Req+0x61 0x44947a: WRK_Thread+0x48a 0x4499eb: pool_thread+0x2b 0x7f3902124b50: libpthread.so.0(+0x6b50) [0x7f3902124b50] 0x7f3901e6e95d: libc.so.6(clone+0x6d) [0x7f3901e6e95d] req = 0x7f1fe0d86020 { sp = (nil), vxid = 0, step = R_STP_RESTART, req_body = R_BODY_INIT, restarts = 0, esi_level = 0, ws = 0x7f1fe0d86220 { BAD_MAGIC(0x00000000) }, }, http[req] = { -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 20 12:23:19 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Nov 2015 12:23:19 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.9c5d180ca87476f0af857556f072fda0@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by aondio): Replying to [comment:9 Hilaus]: > I have the same problem. Did you resolve it? It's on my to-do list. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 20 13:11:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Nov 2015 13:11:29 -0000 Subject: [Varnish] #1806: one minute delay on return (pipe) and a POST-Request In-Reply-To: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> References: <043.2e737ea61af7354d1ac52a29a065755e@varnish-cache.org> Message-ID: <058.2d8ca015591e30ec156f9dcf120fbaf7@varnish-cache.org> #1806: one minute delay on return (pipe) and a POST-Request ----------------------+----------------------- Reporter: butzi | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ----------------------+----------------------- Comment (by Hilaus): More information: In my case, It?s with POST requests only, and only with Magento (I suppose because Magento uses different VCL from others that POST works fine). With 4.0.3 works perfectly, the problem is only with 4.1. The same system and configuration with 4.0.3 works fine. I update varnish to 4.1, and POST requests starts to fails (it waits 30s and send a timeout). A example when that happens (in this case, the host doesn't have SSL. But with SSL happens the same): {{{ * << Request >> 458793 - Begin req 458790 rxreq - Timestamp Start: 1447974382.917233 0.000000 0.000000 - Timestamp Req: 1447974382.917233 0.000000 0.000000 - ReqStart XX.XX.XX.XX 58583 - ReqMethod POST - ReqURL /checkout/cart/add/uenc/aHR0cDovL3d3dy5tdWVibGVzb3V0bGV0LmVzL21lc2EtZXN0dWRpby1ibGFuY2E,/product/93/form_key/3hgT3E2WEqG4scwk/ - ReqProtocol HTTP/1.1 - ReqHeader Host: www.example.com - ReqHeader Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 - ReqHeader Accept-Encoding: gzip, deflate - ReqHeader Accept-Language: en-us - ReqHeader Content-Type: application/x-www-form-urlencoded - ReqHeader Origin: http://www.example.com - ReqHeader Content-Length: 59 - ReqHeader Connection: keep-alive - ReqHeader User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.7 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.7 - ReqHeader Referer: http://www.example.com/some-product - ReqHeader DNT: 1 - ReqHeader Cookie: adminhtml=ieoo7or9epsnc18c4d9vt8brg2; customer_group=1; external_no_cache=1; frontend=2a56054eba7a4a7a896447b305372ee4; persistent_shopping_cart=cYHH5sXPRS7KeXFmzr4RG4bG3b58xlwXJVJKgtpNcgjOKdndVH; __utma=56641590.1642689172.1423557126.1447941509. - ReqHeader X-Forwarded-For: XX.XX.XX.XX - VCL_call RECV - ReqUnset X-Forwarded-For: XX.XX.XX.XX - ReqHeader X-Forwarded-For: XX.XX.XX.XX, XX.XX.XX.XX - VCL_return pipe - VCL_call HASH - VCL_return lookup - Link bereq 458794 pipe - Timestamp Pipe: 1447974382.917345 0.000112 0.000112 - Timestamp PipeSess: 1447974412.917846 30.000613 30.000501 - PipeAcct 1118 1175 0 0 - End }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 20 21:38:34 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Nov 2015 21:38:34 -0000 Subject: [Varnish] #1666: make init script check config before restarting In-Reply-To: <050.d39f2f7511b733263cce920f8a427047@varnish-cache.org> References: <050.d39f2f7511b733263cce920f8a427047@varnish-cache.org> Message-ID: <065.22d745d6af0b9f9053f7f9b3ad3af026@varnish-cache.org> #1666: make init script check config before restarting --------------------------+----------------------- Reporter: KlavsKlavsen | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: | --------------------------+----------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: 4.0 builds now use the same packaging files as 4.1, and have these changes. They will be generally available with the next 4.0 release. I don't think there is much to be done with configtest on systemd, except for maybe supplying a separate tool for it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 20 21:39:48 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Nov 2015 21:39:48 -0000 Subject: [Varnish] #1702: RHEL6 Init-script: startup errors piped to /dev/null In-Reply-To: <044.81cb7ae807b7e679852f34b4fe523747@varnish-cache.org> References: <044.81cb7ae807b7e679852f34b4fe523747@varnish-cache.org> Message-ID: <059.509dbc44d7d1e91ad5fdd3bb8c4be6e7@varnish-cache.org> #1702: RHEL6 Init-script: startup errors piped to /dev/null -----------------------+---------------------- Reporter: denisb | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: fixed Keywords: | -----------------------+---------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: Added to 4.0 today, will be in the repository after next 4.0 release. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 20 21:40:28 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 20 Nov 2015 21:40:28 -0000 Subject: [Varnish] #1756: /etc/init.d/varnish reload always returns 0 on debian/ubuntu In-Reply-To: <044.b6984289b41a3c6207dadd00b7d1e379@varnish-cache.org> References: <044.b6984289b41a3c6207dadd00b7d1e379@varnish-cache.org> Message-ID: <059.d46437b599e308cdb38787fccac20b89@varnish-cache.org> #1756: /etc/init.d/varnish reload always returns 0 on debian/ubuntu --------------------------------------------+----------------------- Reporter: fleish | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: fixed Keywords: init init.d reload exit return | --------------------------------------------+----------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: Added to 4.0 today. New packages will be available after the next 4.0 release. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 23 12:05:19 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Nov 2015 12:05:19 -0000 Subject: [Varnish] #1819: Can't access documentation of cookie In-Reply-To: <043.16838e456817cf67d6dbb2acbc693e91@varnish-cache.org> References: <043.16838e456817cf67d6dbb2acbc693e91@varnish-cache.org> Message-ID: <058.516fe45e23d5bb956dacf1be8e957d26@varnish-cache.org> #1819: Can't access documentation of cookie --------------------+------------------------------ Reporter: colas | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Varnish 4.1-TP1 Component: build | Version: 4.1.0 Severity: normal | Resolution: Keywords: | --------------------+------------------------------ Changes (by lkarsten): * owner: => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 23 23:07:37 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 23 Nov 2015 23:07:37 -0000 Subject: [Varnish] #1818: Grace does not work for hit-for-pass objects In-Reply-To: <043.cc2bc4a259a4448c6bd3b40b0d202ef4@varnish-cache.org> References: <043.cc2bc4a259a4448c6bd3b40b0d202ef4@varnish-cache.org> Message-ID: <058.820225a9fd67cffec8b36848975c7069@varnish-cache.org> #1818: Grace does not work for hit-for-pass objects ----------------------+--------------------- Reporter: daghf | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in 51e0af5ad29b9f1c15958c05b67dccfcb2beb95b -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 24 13:28:27 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Nov 2015 13:28:27 -0000 Subject: [Varnish] #1821: Transient storage not freed straight away on HFP Message-ID: <043.a918f82391e3c733396d7817425c6488@varnish-cache.org> #1821: Transient storage not freed straight away on HFP ----------------------+------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- In the hit-for-pass case, the storage is used until ttl + grace + keep. If the user fall backs to the builtin VCL it means 130s unless it has changed the grace period. Test case attached. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Nov 24 14:29:25 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 24 Nov 2015 14:29:25 -0000 Subject: [Varnish] #1821: Transient storage not freed straight away on HFP In-Reply-To: <043.a918f82391e3c733396d7817425c6488@varnish-cache.org> References: <043.a918f82391e3c733396d7817425c6488@varnish-cache.org> Message-ID: <058.291062c1d090f67e6283f1bfe06fed65@varnish-cache.org> #1821: Transient storage not freed straight away on HFP ----------------------+---------------------------------------- Reporter: fgsch | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * owner: => Poul-Henning Kamp * status: new => closed * resolution: => fixed Comment: In [c2a3f93d1af81fe89966fce28a752cc8dc078704]: {{{ #!CommitTicketReference repository="" revision="c2a3f93d1af81fe89966fce28a752cc8dc078704" Always slim private & pass objects after delivery. Fixes: #1821 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Nov 25 09:27:22 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 25 Nov 2015 09:27:22 -0000 Subject: [Varnish] #1820: Assert error in SES_Delete In-Reply-To: <045.e76209f816c7781b0f5ad7c7524e235d@varnish-cache.org> References: <045.e76209f816c7781b0f5ad7c7524e235d@varnish-cache.org> Message-ID: <060.363b294266eae50ffd6f304aa47251d4@varnish-cache.org> #1820: Assert error in SES_Delete --------------------------+------------------------ Reporter: llavaud | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0-TP1 Severity: normal | Resolution: Keywords: assert error | --------------------------+------------------------ Comment (by phk): I can make neither heads nor tails of this backtrace. There is no way to get from HTTP1_Session() to ses_handle() - which is only called from the waiter (in Wait_Call()) and unless the compiler is positively psychic no optimization can get that far. Something is horribly hosed here, an I have no idea what it is. Unless new evidence emerges, this ticket will time out as "not actionable" around X-mas. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 26 08:40:53 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Nov 2015 08:40:53 -0000 Subject: [Varnish] #1788: ObjIter has terrible performance profile when busyobj != NULL In-Reply-To: <041.000537049e394809a235d0799213d1da@varnish-cache.org> References: <041.000537049e394809a235d0799213d1da@varnish-cache.org> Message-ID: <056.437929c10420b5c788615be1a6c53a04@varnish-cache.org> #1788: ObjIter has terrible performance profile when busyobj != NULL --------------------+---------------------------------------- Reporter: tnt | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | --------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [77fec1b05b3517b0cd211c3771558a9003158754]: {{{ #!CommitTicketReference repository="" revision="77fec1b05b3517b0cd211c3771558a9003158754" Cache a checkpoint when we iterate over busy objects, so we don't have to walk the full list all the time. This is a minimal fix for backporting to 4.1.x Fixes: #1798 Fixes: #1788 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 26 08:40:53 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Nov 2015 08:40:53 -0000 Subject: [Varnish] #1798: Varnish requests painfully slow with large files In-Reply-To: <045.b9933fc5ccad71abef136d693b22f22f@varnish-cache.org> References: <045.b9933fc5ccad71abef136d693b22f22f@varnish-cache.org> Message-ID: <060.5bd12de9527228ea7c47dccf95619828@varnish-cache.org> #1798: Varnish requests painfully slow with large files ----------------------+---------------------------------------- Reporter: nbetham | Owner: Poul-Henning Kamp Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: | ----------------------+---------------------------------------- Changes (by Poul-Henning Kamp ): * status: new => closed * owner: => Poul-Henning Kamp * resolution: => fixed Comment: In [77fec1b05b3517b0cd211c3771558a9003158754]: {{{ #!CommitTicketReference repository="" revision="77fec1b05b3517b0cd211c3771558a9003158754" Cache a checkpoint when we iterate over busy objects, so we don't have to walk the full list all the time. This is a minimal fix for backporting to 4.1.x Fixes: #1798 Fixes: #1788 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 26 14:41:44 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Nov 2015 14:41:44 -0000 Subject: [Varnish] #1822: Assert error in vwe_thread(), waiter/cache_waiter_epoll.c line 114 Message-ID: <046.2bf823d71af9df795c274ab5f9520938@varnish-cache.org> #1822: Assert error in vwe_thread(), waiter/cache_waiter_epoll.c line 114 ----------------------+------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+------------------- While playing around with GDB and setting thread names on Linux, I ran into this: {{{ varnish> panic.show 200 Panic at: Thu, 26 Nov 2015 14:32:58 GMT "Assert error in vwe_thread(), waiter/cache_waiter_epoll.c line 114: Condition(n >= 0) not true. errno = 4 (Interrupted system call) thread = (cache-epoll) version = varnish-trunk revision 83aa540 ident = Linux,3.16.0-4-amd64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x43c1a9: pan_backtrace+0x1d 0x43c5ae: pan_ic+0x2bc 0x47d82c: vwe_thread+0x3c4 0x7faf135200a4: libpthread.so.0(+0x80a4) [0x7faf135200a4] 0x7faf1325504d: libc.so.6(clone+0x6d) [0x7faf1325504d] " }}} Being able to attach a debugger to a running Varnish is quite useful. This may be as simple as handling EINTR return instead of asserting. Coincidentally, the thread name work started with debugging a possible waiter issue. Very nice symmetry. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Nov 26 17:28:15 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 26 Nov 2015 17:28:15 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up Message-ID: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+-------------------- Reporter: hamed.gholamian | Type: defect Status: new | Priority: normal Milestone: Varnish 4.1-TP1 | Component: build Version: 4.1.0 | Severity: normal Keywords: | -----------------------------+-------------------- Hi, We have a problem with Varnish holding onto VCL in a discarded state, which has persisting referenced objects. We timestamp our VCL as a reference to the date/time it was loaded. This is done using a simple script using varnishadm commands. We should only retain 3 'available' configs. The problem being experienced is with the 'discarded' VCL, specifically the backend polling, which being duplicated. This is causing some customers to see high volumes of probes from our delivery servers, which is in turn affecting their backend systems. Example output from varnishadm - {{{ discarded auto/cooling 52 vcl_20151125095333 discarded auto/cooling 11 vcl_20151125122048 discarded auto/cooling 136 vcl_20151125122328 discarded auto/cooling 24 vcl_20151125140126 discarded auto/cooling 1 vcl_20151125143340 discarded auto/cooling 1 vcl_20151125144531 discarded auto/cooling 12 vcl_20151125145312 discarded auto/cooling 9 vcl_20151125154306 discarded auto/cooling 2 vcl_20151125162540 available auto/cold 0 vcl_20151126140831 available auto/cold 0 vcl_20151126141010 available auto/cold 0 vcl_20151126141620 active auto/warm 22 vcl_20151126142113 }}} The referenced objects never reduce, leaving the 'discarded' VCL on the delivery server. We have been able to reproduce this in our development environment doing the following - 1. On the varnish delivery server, create a backend (with no probe) and then a remote backend with simple website. 2. Sending requests (like 1000) to varnish delivery server. 3. On the backend add a new iptables rule to drop port 80. 4. Reload the VCL a number of times. {{{ OS: 12.04 3.2.0-70-generic #105-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux Varnish: varnishd (varnish-4.1.0 revision 3041728) }}} Other than restarting varnish, we have not found a mechanism to clear these and allow the auto/cooling process to complete, removing the VCL. Is this a possible bug or is this expected behavior of the v4.1 VMOD, when backends become sick/unreachable? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 08:40:25 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 08:40:25 -0000 Subject: [Varnish] #1824: Varnish.service should be using type=notify Message-ID: <045.58c9af67e0a10c0550f67baaaa3ea44f@varnish-cache.org> #1824: Varnish.service should be using type=notify ---------------------+---------------------- Reporter: zmyrgel | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 4.0.3 | Severity: normal Keywords: systemd | ---------------------+---------------------- I'm running several Varnishd / varnishncsa instances on our RHEL 7 servers. There seems to be incorrect assumptions in the varnish.service systemd file about starting of varnishd. The service file uses Type=forking. As far as I've understood, this makes Varnishd fork and that will signal that the Varnishd is ready and running. Problem appears to be with VSM files. The VSM files are not necessarily ready when Varnishd reports itself ready. This makes following Varnishncsa processes fail with messsages: Can't open VSM file (Abandoned VSM file (Varnish not running?) /var/lib/varnish/example/_.vsm" What I've gathered the from looking at systemd is that Varnishd process should use systemd's [http://www.freedesktop.org/software/systemd/man/sd_notify.html sd_notify(3)] to signal when the VSM is ready. I'm making assumption here that running multiple varnish instances on same computer makes the creation of VSM files slower which causes the issue to pop up. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 15:19:28 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 15:19:28 -0000 Subject: [Varnish] #1690: CentOS 7 init script is broken due to two separate pidfiles In-Reply-To: <047.01e68cf1abaae063ed09786b9e8d679f@varnish-cache.org> References: <047.01e68cf1abaae063ed09786b9e8d679f@varnish-cache.org> Message-ID: <062.88e7ccabac8d861846aaafe9816b8343@varnish-cache.org> #1690: CentOS 7 init script is broken due to two separate pidfiles -----------------------+--------------------------------------------- Reporter: alexzorin | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: 3.0.5 Severity: normal | Resolution: fixed Keywords: | -----------------------+--------------------------------------------- Comment (by lkarsten): Verified fixed in new 4.0 and 4.1 packaging. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 15:27:01 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 15:27:01 -0000 Subject: [Varnish] #1824: Varnish.service should be using type=notify In-Reply-To: <045.58c9af67e0a10c0550f67baaaa3ea44f@varnish-cache.org> References: <045.58c9af67e0a10c0550f67baaaa3ea44f@varnish-cache.org> Message-ID: <060.e4e0737fdf6708d3521f7570f3a7653c@varnish-cache.org> #1824: Varnish.service should be using type=notify ----------------------+-------------------- Reporter: zmyrgel | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: systemd | ----------------------+-------------------- Comment (by lkarsten): If you are running multiple instances, you are using your own init script? I looked at this last week, and my conclusion then was that it is far cheaper to add `-t 60` or even `-t off` to varnishncsa (and varnishlog) startup command line instead. Currently -t is available in Varnish 4.1 and git master. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 15:28:26 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 15:28:26 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up In-Reply-To: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> References: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> Message-ID: <068.fd20d94397c7dd92dd1865a07680c51c@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+-------------------- Reporter: hamed.gholamian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Changes (by fgsch): * component: build => varnishd * milestone: Varnish 4.1-TP1 => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 15:35:52 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 15:35:52 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up In-Reply-To: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> References: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> Message-ID: <068.1eb1763517cd0a1ffd818d3f844bafbb@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+-------------------- Reporter: hamed.gholamian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Description changed by fgsch: Old description: > Hi, > > We have a problem with Varnish holding onto VCL in a discarded state, > which has persisting referenced objects. > > We timestamp our VCL as a reference to the date/time it was loaded. This > is done using a simple script using varnishadm commands. We should only > retain 3 'available' configs. > > The problem being experienced is with the 'discarded' VCL, specifically > the backend polling, which being duplicated. This is causing some > customers to see high volumes of probes from our delivery servers, which > is in turn affecting their backend systems. > > Example output from varnishadm - > > {{{ > discarded auto/cooling 52 vcl_20151125095333 > discarded auto/cooling 11 vcl_20151125122048 > discarded auto/cooling 136 vcl_20151125122328 > discarded auto/cooling 24 vcl_20151125140126 > discarded auto/cooling 1 vcl_20151125143340 > discarded auto/cooling 1 vcl_20151125144531 > discarded auto/cooling 12 vcl_20151125145312 > discarded auto/cooling 9 vcl_20151125154306 > discarded auto/cooling 2 vcl_20151125162540 > available auto/cold 0 vcl_20151126140831 > available auto/cold 0 vcl_20151126141010 > available auto/cold 0 vcl_20151126141620 > active auto/warm 22 vcl_20151126142113 > }}} > > The referenced objects never reduce, leaving the 'discarded' VCL on the > delivery server. > > We have been able to reproduce this in our development environment doing > the following - > > 1. On the varnish delivery server, create a backend (with no probe) and > then a remote backend with simple website. > 2. Sending requests (like 1000) to varnish delivery server. > 3. On the backend add a new iptables rule to drop port 80. > 4. Reload the VCL a number of times. > > {{{ > OS: 12.04 3.2.0-70-generic #105-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux > Varnish: varnishd (varnish-4.1.0 revision 3041728) > > }}} > > Other than restarting varnish, we have not found a mechanism to clear > these and allow the auto/cooling process to complete, removing the VCL. > > Is this a possible bug or is this expected behavior of the v4.1 VMOD, > when backends become sick/unreachable? New description: Hi, We have a problem with Varnish holding onto VCL in a discarded state, which has persisting referenced objects. We timestamp our VCL as a reference to the date/time it was loaded. This is done using a simple script using varnishadm commands. We should only retain 3 'available' configs. The problem being experienced is with the 'discarded' VCL, specifically the backend polling, which being duplicated. This is causing some customers to see high volumes of probes from our delivery servers, which is in turn affecting their backend systems. Example output from varnishadm - {{{ discarded auto/cooling 52 vcl_20151125095333 discarded auto/cooling 11 vcl_20151125122048 discarded auto/cooling 136 vcl_20151125122328 discarded auto/cooling 24 vcl_20151125140126 discarded auto/cooling 1 vcl_20151125143340 discarded auto/cooling 1 vcl_20151125144531 discarded auto/cooling 12 vcl_20151125145312 discarded auto/cooling 9 vcl_20151125154306 discarded auto/cooling 2 vcl_20151125162540 available auto/cold 0 vcl_20151126140831 available auto/cold 0 vcl_20151126141010 available auto/cold 0 vcl_20151126141620 active auto/warm 22 vcl_20151126142113 }}} The referenced objects never reduce, leaving the 'discarded' VCL on the delivery server. We have been able to reproduce this in our development environment doing the following - 1. On the varnish delivery server, create a backend (with no probe) and then a remote backend with simple website. 3. On the backend add a new iptables rule to drop port 80. 2. Sending requests (like 1000) to varnish delivery server. 4. Reload the VCL a number of times. {{{ OS: 12.04 3.2.0-70-generic #105-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux Varnish: varnishd (varnish-4.1.0 revision 3041728) }}} Other than restarting varnish, we have not found a mechanism to clear these and allow the auto/cooling process to complete, removing the VCL. Is this a possible bug or is this expected behavior of the v4.1 VMOD, when backends become sick/unreachable? -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 15:37:09 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 15:37:09 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up In-Reply-To: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> References: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> Message-ID: <068.1e9a15f828beba9ccaa05d6ca4e233c8@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+-------------------- Reporter: hamed.gholamian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Description changed by fgsch: Old description: > Hi, > > We have a problem with Varnish holding onto VCL in a discarded state, > which has persisting referenced objects. > > We timestamp our VCL as a reference to the date/time it was loaded. This > is done using a simple script using varnishadm commands. We should only > retain 3 'available' configs. > > The problem being experienced is with the 'discarded' VCL, specifically > the backend polling, which being duplicated. This is causing some > customers to see high volumes of probes from our delivery servers, which > is in turn affecting their backend systems. > > Example output from varnishadm - > > {{{ > discarded auto/cooling 52 vcl_20151125095333 > discarded auto/cooling 11 vcl_20151125122048 > discarded auto/cooling 136 vcl_20151125122328 > discarded auto/cooling 24 vcl_20151125140126 > discarded auto/cooling 1 vcl_20151125143340 > discarded auto/cooling 1 vcl_20151125144531 > discarded auto/cooling 12 vcl_20151125145312 > discarded auto/cooling 9 vcl_20151125154306 > discarded auto/cooling 2 vcl_20151125162540 > available auto/cold 0 vcl_20151126140831 > available auto/cold 0 vcl_20151126141010 > available auto/cold 0 vcl_20151126141620 > active auto/warm 22 vcl_20151126142113 > }}} > > The referenced objects never reduce, leaving the 'discarded' VCL on the > delivery server. > > We have been able to reproduce this in our development environment doing > the following - > > 1. On the varnish delivery server, create a backend (with no probe) and > then a remote backend with simple website. > 3. On the backend add a new iptables rule to drop port 80. > 2. Sending requests (like 1000) to varnish delivery server. > 4. Reload the VCL a number of times. > > {{{ > OS: 12.04 3.2.0-70-generic #105-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux > Varnish: varnishd (varnish-4.1.0 revision 3041728) > > }}} > > Other than restarting varnish, we have not found a mechanism to clear > these and allow the auto/cooling process to complete, removing the VCL. > > Is this a possible bug or is this expected behavior of the v4.1 VMOD, > when backends become sick/unreachable? New description: Hi, We have a problem with Varnish holding onto VCL in a discarded state, which has persisting referenced objects. We timestamp our VCL as a reference to the date/time it was loaded. This is done using a simple script using varnishadm commands. We should only retain 3 'available' configs. The problem being experienced is with the 'discarded' VCL, specifically the backend polling, which being duplicated. This is causing some customers to see high volumes of probes from our delivery servers, which is in turn affecting their backend systems. Example output from varnishadm - {{{ discarded auto/cooling 52 vcl_20151125095333 discarded auto/cooling 11 vcl_20151125122048 discarded auto/cooling 136 vcl_20151125122328 discarded auto/cooling 24 vcl_20151125140126 discarded auto/cooling 1 vcl_20151125143340 discarded auto/cooling 1 vcl_20151125144531 discarded auto/cooling 12 vcl_20151125145312 discarded auto/cooling 9 vcl_20151125154306 discarded auto/cooling 2 vcl_20151125162540 available auto/cold 0 vcl_20151126140831 available auto/cold 0 vcl_20151126141010 available auto/cold 0 vcl_20151126141620 active auto/warm 22 vcl_20151126142113 }}} The referenced objects never reduce, leaving the 'discarded' VCL on the delivery server. We have been able to reproduce this in our development environment doing the following - 1. On the varnish delivery server, create a backend (with no probe) and then a remote backend with simple website. 3. On the backend add a new iptables rule to drop port 80. 2. Sending requests (like 1000) to varnish delivery server. 4. Reload the VCL a number of times. {{{ OS: 12.04 3.2.0-70-generic #105-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux Varnish: varnishd (varnish-4.1.0 revision 3041728) }}} Other than restarting varnish, we have not found a mechanism to clear these and allow the auto/cooling process to complete, removing the VCL. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 15:38:43 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 15:38:43 -0000 Subject: [Varnish] #1824: Varnish.service should be using type=notify In-Reply-To: <045.58c9af67e0a10c0550f67baaaa3ea44f@varnish-cache.org> References: <045.58c9af67e0a10c0550f67baaaa3ea44f@varnish-cache.org> Message-ID: <060.ffd574e454ed34a2bd5e38dd7a1e41d0@varnish-cache.org> #1824: Varnish.service should be using type=notify ----------------------+-------------------- Reporter: zmyrgel | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: systemd | ----------------------+-------------------- Comment (by lkarsten): Related: -t option introduced after #1674 discussion. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 16:04:25 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 16:04:25 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition In-Reply-To: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> References: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> Message-ID: <064.35eb97f6310606bba66152a33cb18c33@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+----------------------------------------- Reporter: huguesalary | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: fixed Keywords: | -------------------------+----------------------------------------- Comment (by lkarsten): Reviewed this for 4.0.4. The dropbox links are dead. As far as I can tell, crashing on extensive regexes can be worked around by increasing thread_pool_stack. Backporting JIT change mid-4.0 is no go, we tried that in 3.0.4. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 18:53:39 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 18:53:39 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition In-Reply-To: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> References: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> Message-ID: <064.a8a016ca0d5cec10b82dca0f39ac24df@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+----------------------------------------- Reporter: huguesalary | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: fixed Keywords: | -------------------------+----------------------------------------- Comment (by paluna): Thanks lkarsten. We upgraded to varnish-4.1.0 revision 3041728 in October 2015 and use the settings as documented below. Setting thread_pool_stack=72k is one of them. The situation is acceptable now. The number of crashes decreased to almost zero (the last Varnish crash goes back to Nov 6, 2015). In order to be complete I have uploaded a new set of crashdump files for your info. Environment: Ubuntu 14.04.2 LTS varnishd (varnish-4.1.0 revision 3041728) command line: "/usr/sbin/varnishd -P /run/varnishd.pid -a :80 -T localhost:6082 -t 600 -f /etc/varnish/cloud.vcl -S /etc/varnish/secret -p pcre_match_limit=2500 -p pcre_match_limit_recursion=500 -p thread_pool_stack=72k -s file,/var/lib/varnish/cloud/varnish_storage.bin,100M" This is the last crashdump of 20151106: https://dl.dropboxusercontent.com/u/5629939/temp/20151106%202312h%20varnishd.7z Replying to [comment:6 lkarsten]: > Reviewed this for 4.0.4. The dropbox links are dead. > As far as I can tell, crashing on extensive regexes can be worked around by increasing thread_pool_stack. Backporting JIT change mid-4.0 is no go, we tried that in 3.0.4. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 19:46:19 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 19:46:19 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition In-Reply-To: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> References: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> Message-ID: <064.87582dea1017e6c0e1bee71ca507e86f@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+----------------------------------------- Reporter: huguesalary | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: fixed Keywords: | -------------------------+----------------------------------------- Comment (by fgsch): Can you enable coredumps (e.g. ulimit -c unlimited)? When it crashes is there anything else under syslog or varnishadm panic.show? Are you using any VMODs besides std? Is varnish installed from repo .varnish-cache.org? Sharing your VCL might also help. There is no much info in the crashdump and I cannot reproduce it using your pcre limits. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Nov 27 19:48:16 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 27 Nov 2015 19:48:16 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up In-Reply-To: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> References: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> Message-ID: <068.b8d0dbbc7f08496b98cee5f6e9ee9284@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+-------------------- Reporter: hamed.gholamian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Comment (by fgsch): Via IRC: using epoll with default timeouts. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Nov 29 14:38:02 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 29 Nov 2015 14:38:02 -0000 Subject: [Varnish] #1630: Varnish crashes with long regex condition In-Reply-To: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> References: <049.e52d1e681fb29ad347dd951ccb0f4fa2@varnish-cache.org> Message-ID: <064.fe98ac926dbda810a2977c428b19f441@varnish-cache.org> #1630: Varnish crashes with long regex condition -------------------------+----------------------------------------- Reporter: huguesalary | Owner: Tollef Fog Heen Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.2 Severity: normal | Resolution: fixed Keywords: | -------------------------+----------------------------------------- Comment (by paluna): Thanks for the suggestions. I will submit a new (full) crash dump and config files as soon as a new crash happens again. Note that it only crashes about once a month which makes it difficult. At that point I will share my main VCL as well. 0. I have now changed the core file size to unlimited for the varnish processes. 1. I cannot reproduce it either (not in production, not in the dev environment). The server handles on avg 125K requests/day and I cannot figure out which http request/response causes the crash; maybe it is not related to a specific http req/rsp at all, who knows. The varnish daemon is also restarted once every night at 4am in the production environment. The varnishlog is empty after the crash because the varnishd has been restarted. 2. There is nothing else in syslog. I did not run varnishadm panic.show at the time of the crash. 3. Yes, it is installed from "deb https://repo.varnish-cache.org/ubuntu/ trusty varnish-4.1". 4. The server only imports 1 VMODs, being std. 5. The server config includes a computer generated vcl script with lots of regexp's to detect mobile devices https://gist.github.com/pantaluna/029741e2f299415eceec Replying to [comment:8 fgsch]: > Can you enable coredumps (e.g. ulimit -c unlimited)? > When it crashes is there anything else under syslog or varnishadm panic.show? > Are you using any VMODs besides std? Is varnish installed from repo .varnish-cache.org? > > Sharing your VCL might also help. > > There is no much info in the crashdump and I cannot reproduce it using your pcre limits. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 30 12:04:25 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Nov 2015 12:04:25 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up In-Reply-To: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> References: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> Message-ID: <068.8ccc72e42e08f1662fb944a36c3602fe@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+-------------------- Reporter: hamed.gholamian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Comment (by martin): Reporter has confirmed with netstat that all tcp connections has terminated. This points towards a refcount leak. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 30 12:07:43 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Nov 2015 12:07:43 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up In-Reply-To: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> References: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> Message-ID: <068.2cf5de78ba0a9f0b73b11076036ce0a9@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+-------------------- Reporter: hamed.gholamian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Comment (by martin): More info: {{{ 13:02:13 < phk> (Please add that info to ticket) 13:02:16 < nan0r> me & lupi are the guys 13:02:35 < phk> nan0r, cool, thanks for participating. 13:03:18 < nan0r> phk: you are welcome 13:03:21 < phk> nan0r, what's the regular traffic level ? (Just to get an idea of the frequency of lost references) ? 13:03:23 < lochii> how do we track refcount increments / decrements 13:03:32 < nan0r> us + lochii 13:03:55 < phk> lochii, you shouldn't have to :-) 13:04:13 < phk> lochii, so we don't have any logging for it. 13:04:21 < lochii> so this is the vcl->busy counter? 13:04:25 < phk> however, there may be varnishstat counters that spot this. 13:04:32 < phk> lochii, yes. 13:04:46 -!- hu_made_this_script [Adium at 87.253.171.197] has joined #varnish-hacking 13:04:50 < nan0r> quite a lot of traffic, about 100 backends, 300 req/s, sessions let me check 13:05:11 < phk> so basically, whenever a worker is doing something, it holds a ref on the VCL so that it can call the different methods in the same VCL until the transaction is completed. 13:05:38 < phk> are you using dynamic backends or only static backends ? 13:06:02 < lochii> nan0r: ? 13:06:04 < lochii> I think only static 13:06:05 < nan0r> 50 connections / sec 13:06:16 < phk> lochii, any directors at all ? 13:06:18 < nan0r> phk: static backedns only 13:06:42 < lochii> I dont think any directors 13:06:44 < nan0r> all declared in main vcl, not in vmods 13:06:50 < lochii> yes, no vmods 13:06:58 < phk> cool, that eliminates a lot of variables. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 30 12:16:40 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Nov 2015 12:16:40 -0000 Subject: [Varnish] #1822: Assert error in vwe_thread(), waiter/cache_waiter_epoll.c line 114 In-Reply-To: <046.2bf823d71af9df795c274ab5f9520938@varnish-cache.org> References: <046.2bf823d71af9df795c274ab5f9520938@varnish-cache.org> Message-ID: <061.81a2972aa9cda605ab7263d33d051cdc@varnish-cache.org> #1822: Assert error in vwe_thread(), waiter/cache_waiter_epoll.c line 114 ----------------------+------------------------ Reporter: lkarsten | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: duplicate Keywords: | ----------------------+------------------------ Changes (by lkarsten): * status: new => closed * resolution: => duplicate Comment: Duplicate of #1763. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 30 12:17:02 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Nov 2015 12:17:02 -0000 Subject: [Varnish] #1763: tolerate EINTR in accept() ? In-Reply-To: <043.6d09ee992e18ddcfd4d5c149e6684cb6@varnish-cache.org> References: <043.6d09ee992e18ddcfd4d5c149e6684cb6@varnish-cache.org> Message-ID: <058.8d7d14c2918c09719af11900c3e8326a@varnish-cache.org> #1763: tolerate EINTR in accept() ? ----------------------+-------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Also reported in #1822. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 30 12:39:27 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Nov 2015 12:39:27 -0000 Subject: [Varnish] #1763: tolerate EINTR in accept() ? In-Reply-To: <043.6d09ee992e18ddcfd4d5c149e6684cb6@varnish-cache.org> References: <043.6d09ee992e18ddcfd4d5c149e6684cb6@varnish-cache.org> Message-ID: <058.db4c5b7f987dd26d90868f0947b0f4ba@varnish-cache.org> #1763: tolerate EINTR in accept() ? ----------------------+-------------------- Reporter: slink | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by lkarsten): Agreed on bugwash today: propose a patch for the *poll/kqueue waiters, and see if it is sufficient. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Nov 30 12:46:33 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 30 Nov 2015 12:46:33 -0000 Subject: [Varnish] #1823: vcl in discarded mode does not clear up In-Reply-To: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> References: <053.d5bd7015a6c05d08550e0b9872da3461@varnish-cache.org> Message-ID: <068.92db0da1fd334cc1f109a4124fa5f4ff@varnish-cache.org> #1823: vcl in discarded mode does not clear up -----------------------------+-------------------- Reporter: hamed.gholamian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | -----------------------------+-------------------- Comment (by phk): Examination of counters indicate that this is req's stuck on the waiting list. -- Ticket URL: Varnish The Varnish HTTP Accelerator