From varnish-bugs at varnish-cache.org Wed Dec 2 04:55:49 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Dec 2015 04:55:49 -0000 Subject: [Varnish] #1825: Cannot Start Varnish After Just Restarting The Service Message-ID: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> #1825: Cannot Start Varnish After Just Restarting The Service -----------------------------+---------------------- Reporter: ghostshell | Type: defect Status: new | Priority: normal Milestone: Varnish 4.1-TP1 | Component: varnishd Version: 4.1.0-TP1 | Severity: major Keywords: | -----------------------------+---------------------- I upgraded via the CentOS package manager using the official repo from v4 to v4.1, had a small issue which I got fixed and everything was working fine. I needed to restart the varnish service yesterday and now it shows started but when I check the status of varnish or go to a web site hosted on the server the service shows not started and I cannot access any of my sites. I was able to get the access log going again, but I cannot figure out how to get the log going showing varnish startup/service errors or the success messages when it goes to start so all I have is the log info from messages which is: Nov 30 23:30:42 www varnishd[16665]: Child (16667) not responding to CLI, killing it. Nov 30 23:30:42 www varnishd[16665]: Child (16667) died signal=11 (core dumped) Nov 30 23:30:42 www varnishd[16665]: Child (16667) Panic message:#012 Assert error in child_sigsegv_handler(), mgt/mgt_child.c line 297:#012 Condition(Segmentation fault by instruction at 0x205970) not true.#012thread = (cache-worker)#012version = varnish-4.1.0 revision 3041728#012ident = Linux,2.6.32-573.8.1.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x432483: varnishd() [0x432483]#012 0x450de9: varnishd() [0x450de9]#012 0x34a480f790: libpthread.so.0() [0x34a480f790]#012 0x43c2b9: varnishd(VCL_DefaultDirector+0x19) [0x43c2b9]#012 0x436b9e: varnishd(CNT_Request+0x74e) [0x436b9e]#012 0x44cc3b: varnishd(HTTP1_Session+0x11b) [0x44cc3b]#012 0x439921: varnishd(SES_Proto_Req+0x61) [0x439921]#012 0x447aed: varnishd() [0x447aed]#012 0x447eeb: varnishd() [0x447eeb]#012 0x34a4807a51: libpthread.so.0() [0x34a4807a51]#012req = 0x7fe026896020 {#012 vxid = 2, step = R_STP_RECV,#012 req_body = R_BODY_NONE,#012 restarts = 0, esi_level = 0,#012 sp = 0x7fe02640f420 {#012 fd = 13, vxid = 1,#012 client = 180.76.15.6 56796,#012 step = S_STP_H1PROC,#012 },#012 worker = 0x7fe02d7eebc0 {#012 stack = {0x7fe02d7ef000 -> 0x7fe02d7e3000},#012 ws = 0x7fe02d7eedb8 {#012 id = "wrk",#012 {s,f,r,e} = {0x7fe02d7ee380,0x7fe02d7ee380,(nil),+2040},#012 },#012 VCL::method = none,#012 ws = 0x7fe026896200 {#012 id = "req",#012 {s,f,r,e} = {0x7fe026898000,+216,(nil),+57336},#012 },#012 http_conn = 0x7fe026896128 {#012 fd = 13,#012 doclose = NULL,#012 ws = 0x7fe026896200,#012 {rxbuf_b, rxbuf_e} = {0x7fe026898000, 0x7fe0268980b8},#012 {pipeline_b, pipeline_e} = {(nil), (nil)},#012 content_length = -1,#012 body_status = none,#012 first_byte_timeout = 0.000000,#012 between_bytes_timeout = 0.000000,#012 },#012 http[req] = 0x7fe026896298 {#012 ws[req] = 0x7fe026896200,#012 hdrs {#012 "GET",#012 "/",#012 "HTTP/1.1",#012 "Host: wsww",#012 "Accept-Lang Nov 30 23:30:42 www varnishd[16665]: child (17228) Started Nov 30 23:30:43 www varnishd[16665]: Pushing vcls failed:#012Could not load compiled VCL.#012#011dlopen(vcl_boot/vgc.so) = vcl_boot/vgc.so: cannot open shared object file: No such file or directory Nov 30 23:30:44 www varnishd[16665]: Child (17228) ended Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child starts Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child dies Nov 30 23:31:53 www named[2444]: error (network unreachable) resolving 'www.amazon.it/A/IN': 2001:502:4612::1#53 Nov 30 23:32:20 www varnishd[16665]: Manager got SIGINT Nov 30 23:32:24 www varnishd[18670]: Platform: Linux,2.6.32-573.8.1.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbit Nov 30 23:32:24 www varnishd[18670]: child (18672) Started Nov 30 23:32:24 www varnishd[18670]: Child (18672) said Child starts Nov 30 23:32:51 www varnishd[18670]: Manager got SIGINT Nov 30 23:32:52 www varnishd[18670]: Child (18672) ended Nov 30 23:32:52 www varnishd[18670]: Child (18672) said Child die All my sites are currently down, the only solution I have for the moment is to downgrade to 4.0 from 4.1.0-1. I tested the downgrade and the service and my sites came right online once the downgrade was complete. I would like to keep updated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 2 04:57:23 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Dec 2015 04:57:23 -0000 Subject: [Varnish] #1825: Cannot Start Varnish After Just Restarting The Service In-Reply-To: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> References: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> Message-ID: <063.053b88dea92766a692ab1dc61b008fdc@varnish-cache.org> #1825: Cannot Start Varnish After Just Restarting The Service ------------------------+------------------------------ Reporter: ghostshell | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.1-TP1 Component: varnishd | Version: 4.1.0-TP1 Severity: major | Resolution: Keywords: | ------------------------+------------------------------ Comment (by ghostshell): Sorry for the formatting, I cannot find a way to modify the ticket to fix the log formatting -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 2 09:34:45 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Dec 2015 09:34:45 -0000 Subject: [Varnish] #1825: Cannot Start Varnish After Just Restarting The Service In-Reply-To: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> References: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> Message-ID: <063.572508ec67ec57f3ded05771629ecc6a@varnish-cache.org> #1825: Cannot Start Varnish After Just Restarting The Service ------------------------+-------------------- Reporter: ghostshell | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ------------------------+-------------------- Changes (by fgsch): * version: 4.1.0-TP1 => 4.1.0 * milestone: Varnish 4.1-TP1 => Old description: > I upgraded via the CentOS package manager using the official repo from v4 > to v4.1, had a small issue which I got fixed and everything was working > fine. I needed to restart the varnish service yesterday and now it shows > started but when I check the status of varnish or go to a web site hosted > on the server the service shows not started and I cannot access any of my > sites. I was able to get the access log going again, but I cannot figure > out how to get the log going showing varnish startup/service errors or > the success messages when it goes to start so all I have is the log info > from messages which is: > > Nov 30 23:30:42 www varnishd[16665]: Child (16667) not responding to CLI, > killing it. > Nov 30 23:30:42 www varnishd[16665]: Child (16667) died signal=11 (core > dumped) > Nov 30 23:30:42 www varnishd[16665]: Child (16667) Panic message:#012 > Assert error in child_sigsegv_handler(), mgt/mgt_child.c line 297:#012 > Condition(Segmentation fault by instruction at 0x205970) not > true.#012thread = (cache-worker)#012version = varnish-4.1.0 revision > 3041728#012ident = > Linux,2.6.32-573.8.1.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x432483: varnishd() [0x432483]#012 0x450de9: varnishd() [0x450de9]#012 > 0x34a480f790: libpthread.so.0() [0x34a480f790]#012 0x43c2b9: > varnishd(VCL_DefaultDirector+0x19) [0x43c2b9]#012 0x436b9e: > varnishd(CNT_Request+0x74e) [0x436b9e]#012 0x44cc3b: > varnishd(HTTP1_Session+0x11b) [0x44cc3b]#012 0x439921: > varnishd(SES_Proto_Req+0x61) [0x439921]#012 0x447aed: varnishd() > [0x447aed]#012 0x447eeb: varnishd() [0x447eeb]#012 0x34a4807a51: > libpthread.so.0() [0x34a4807a51]#012req = 0x7fe026896020 {#012 vxid = 2, > step = R_STP_RECV,#012 req_body = R_BODY_NONE,#012 restarts = 0, > esi_level = 0,#012 sp = 0x7fe02640f420 {#012 fd = 13, vxid = 1,#012 > client = 180.76.15.6 56796,#012 step = S_STP_H1PROC,#012 },#012 > worker = 0x7fe02d7eebc0 {#012 stack = {0x7fe02d7ef000 -> > 0x7fe02d7e3000},#012 ws = 0x7fe02d7eedb8 {#012 id = "wrk",#012 > {s,f,r,e} = {0x7fe02d7ee380,0x7fe02d7ee380,(nil),+2040},#012 },#012 > VCL::method = none,#012 ws = 0x7fe026896200 {#012 id = "req",#012 > {s,f,r,e} = {0x7fe026898000,+216,(nil),+57336},#012 },#012 > http_conn = 0x7fe026896128 {#012 fd = 13,#012 doclose = > NULL,#012 ws = 0x7fe026896200,#012 {rxbuf_b, rxbuf_e} = > {0x7fe026898000, 0x7fe0268980b8},#012 {pipeline_b, pipeline_e} = > {(nil), (nil)},#012 content_length = -1,#012 body_status = > none,#012 first_byte_timeout = 0.000000,#012 > between_bytes_timeout = 0.000000,#012 },#012 http[req] = > 0x7fe026896298 {#012 ws[req] = 0x7fe026896200,#012 hdrs {#012 > "GET",#012 "/",#012 "HTTP/1.1",#012 "Host: > wsww",#012 "Accept-Lang > Nov 30 23:30:42 www varnishd[16665]: child (17228) Started > Nov 30 23:30:43 www varnishd[16665]: Pushing vcls failed:#012Could not > load compiled VCL.#012#011dlopen(vcl_boot/vgc.so) = vcl_boot/vgc.so: > cannot open shared object file: No such file or directory > Nov 30 23:30:44 www varnishd[16665]: Child (17228) ended > Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child starts > Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child dies > Nov 30 23:31:53 www named[2444]: error (network unreachable) resolving > 'www.amazon.it/A/IN': 2001:502:4612::1#53 > Nov 30 23:32:20 www varnishd[16665]: Manager got SIGINT > Nov 30 23:32:24 www varnishd[18670]: Platform: > Linux,2.6.32-573.8.1.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbit > Nov 30 23:32:24 www varnishd[18670]: child (18672) Started > Nov 30 23:32:24 www varnishd[18670]: Child (18672) said Child starts > Nov 30 23:32:51 www varnishd[18670]: Manager got SIGINT > Nov 30 23:32:52 www varnishd[18670]: Child (18672) ended > Nov 30 23:32:52 www varnishd[18670]: Child (18672) said Child die > > All my sites are currently down, the only solution I have for the moment > is to downgrade to 4.0 from 4.1.0-1. I tested the downgrade and the > service and my sites came right online once the downgrade was complete. I > would like to keep updated. New description: I upgraded via the CentOS package manager using the official repo from v4 to v4.1, had a small issue which I got fixed and everything was working fine. I needed to restart the varnish service yesterday and now it shows started but when I check the status of varnish or go to a web site hosted on the server the service shows not started and I cannot access any of my sites. I was able to get the access log going again, but I cannot figure out how to get the log going showing varnish startup/service errors or the success messages when it goes to start so all I have is the log info from messages which is: {{{ Nov 30 23:30:42 www varnishd[16665]: Child (16667) not responding to CLI, killin g it. Nov 30 23:30:42 www varnishd[16665]: Child (16667) died signal=11 (core dumped) Nov 30 23:30:42 www varnishd[16665]: Child (16667) Panic message: Assert error in child_sigsegv_handler(), mgt/mgt_child.c line 297: Condition(Segmentation fault by instruction at 0x205970) not true. thread = (cache-worker) version = varnish-4.1.0 revision 3041728 ident = Linux,2.6.32-573.8.1.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbi t,epoll Backtrace: 0x432483: varnishd() [0x432483] 0x450de9: varnishd() [0x450de9] 0x34a480f790: libpthread.so.0() [0x34a480f790] 0x43c2b9: varnishd(VCL_DefaultDirector+0x19) [0x43c2b9] 0x436b9e: varnishd(CNT_Request+0x74e) [0x436b9e] 0x44cc3b: varnishd(HTTP1_Session+0x11b) [0x44cc3b] 0x439921: varnishd(SES_Proto_Req+0x61) [0x439921] 0x447aed: varnishd() [0x447aed] 0x447eeb: varnishd() [0x447eeb] 0x34a4807a51: libpthread.so.0() [0x34a4807a51] req = 0x7fe026896020 { vxid = 2, step = R_STP_RECV, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7fe02640f420 { fd = 13, vxid = 1, client = 180.76.15.6 56796, step = S_STP_H1PROC, }, worker = 0x7fe02d7eebc0 { stack = {0x7fe02d7ef000 -> 0x7fe02d7e3000}, ws = 0x7fe02d7eedb8 { id = "wrk", {s,f,r,e} = {0x7fe02d7ee380,0x7fe02d7ee380,(nil),+2040}, }, VCL::method = none, ws = 0x7fe026896200 { id = "req", {s,f,r,e} = {0x7fe026898000,+216,(nil),+57336}, }, http_conn = 0x7fe026896128 { fd = 13, doclose = NULL, ws = 0x7fe026896200, {rxbuf_b, rxbuf_e} = {0x7fe026898000, 0x7fe0268980b8}, {pipeline_b, pipeline_e} = {(nil), (nil)}, content_length = -1, body_status = none, first_byte_timeout = 0.000000, between_bytes_timeout = 0.000000, }, http[req] = 0x7fe026896298 { ws[req] = 0x7fe026896200, hdrs { "GET", "/", "HTTP/1.1", "Host: wsww", "Accept-Lang Nov 30 23:30:42 www varnishd[16665]: child (17228) Started Nov 30 23:30:43 www varnishd[16665]: Pushing vcls failed: Could not load compiled VCL. #011dlopen(vcl_boot/vgc.so) = vcl_boot/vgc.so: cannot open shared object file: N o such file or directory Nov 30 23:30:44 www varnishd[16665]: Child (17228) ended Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child starts Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child dies Nov 30 23:31:53 www named[2444]: error (network unreachable) resolving 'www.amaz on.it/A/IN': 2001:502:4612::1#53 Nov 30 23:32:20 www varnishd[16665]: Manager got SIGINT Nov 30 23:32:24 www varnishd[18670]: Platform: Linux,2.6.32-573.8.1.el6.x86_64,x 86_64,-junix,-smalloc,-smalloc,-hcritbit Nov 30 23:32:24 www varnishd[18670]: child (18672) Started Nov 30 23:32:24 www varnishd[18670]: Child (18672) said Child starts Nov 30 23:32:51 www varnishd[18670]: Manager got SIGINT Nov 30 23:32:52 www varnishd[18670]: Child (18672) ended Nov 30 23:32:52 www varnishd[18670]: Child (18672) said Child die }}} All my sites are currently down, the only solution I have for the moment is to downgrade to 4.0 from 4.1.0-1. I tested the downgrade and the service and my sites came right online once the downgrade was complete. I would like to keep updated. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 2 09:41:44 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Dec 2015 09:41:44 -0000 Subject: [Varnish] #1825: Cannot Start Varnish After Just Restarting The Service In-Reply-To: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> References: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> Message-ID: <063.c346369808076171360fae8ee5c0b662@varnish-cache.org> #1825: Cannot Start Varnish After Just Restarting The Service ------------------------+-------------------- Reporter: ghostshell | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ------------------------+-------------------- Description changed by fgsch: Old description: > I upgraded via the CentOS package manager using the official repo from v4 > to v4.1, had a small issue which I got fixed and everything was working > fine. I needed to restart the varnish service yesterday and now it shows > started but when I check the status of varnish or go to a web site hosted > on the server the service shows not started and I cannot access any of > my sites. I was able to get the access log going again, but I cannot > figure out how to get the log going showing varnish startup/service > errors or the success messages when it goes to start so all I have is > the log info from messages which is: > > {{{ > Nov 30 23:30:42 www varnishd[16665]: Child (16667) not responding to CLI, > killin > g it. > Nov 30 23:30:42 www varnishd[16665]: Child (16667) died signal=11 (core > dumped) > Nov 30 23:30:42 www varnishd[16665]: Child (16667) Panic message: > Assert error in child_sigsegv_handler(), mgt/mgt_child.c line 297: > Condition(Segmentation fault by instruction at 0x205970) not true. > thread = (cache-worker) > version = varnish-4.1.0 revision 3041728 > ident = > Linux,2.6.32-573.8.1.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbi > t,epoll > Backtrace: > 0x432483: varnishd() [0x432483] > 0x450de9: varnishd() [0x450de9] > 0x34a480f790: libpthread.so.0() [0x34a480f790] > 0x43c2b9: varnishd(VCL_DefaultDirector+0x19) [0x43c2b9] > 0x436b9e: varnishd(CNT_Request+0x74e) [0x436b9e] > 0x44cc3b: varnishd(HTTP1_Session+0x11b) [0x44cc3b] > 0x439921: varnishd(SES_Proto_Req+0x61) [0x439921] > 0x447aed: varnishd() [0x447aed] > 0x447eeb: varnishd() [0x447eeb] > 0x34a4807a51: libpthread.so.0() [0x34a4807a51] > req = 0x7fe026896020 { > vxid = 2, step = R_STP_RECV, > req_body = R_BODY_NONE, > restarts = 0, esi_level = 0, > sp = 0x7fe02640f420 { > fd = 13, vxid = 1, > client = 180.76.15.6 56796, > step = S_STP_H1PROC, > }, > worker = 0x7fe02d7eebc0 { > stack = {0x7fe02d7ef000 -> 0x7fe02d7e3000}, > ws = 0x7fe02d7eedb8 { > id = "wrk", > {s,f,r,e} = {0x7fe02d7ee380,0x7fe02d7ee380,(nil),+2040}, > }, > VCL::method = none, > ws = 0x7fe026896200 { > id = "req", > {s,f,r,e} = {0x7fe026898000,+216,(nil),+57336}, > }, > http_conn = 0x7fe026896128 { > fd = 13, > doclose = NULL, > ws = 0x7fe026896200, > {rxbuf_b, rxbuf_e} = {0x7fe026898000, 0x7fe0268980b8}, > {pipeline_b, pipeline_e} = {(nil), (nil)}, > content_length = -1, > body_status = none, > first_byte_timeout = 0.000000, > between_bytes_timeout = 0.000000, > }, > http[req] = 0x7fe026896298 { > ws[req] = 0x7fe026896200, > hdrs { > "GET", > "/", > "HTTP/1.1", > "Host: wsww", > "Accept-Lang > Nov 30 23:30:42 www varnishd[16665]: child (17228) Started > Nov 30 23:30:43 www varnishd[16665]: Pushing vcls failed: > Could not load compiled VCL. > #011dlopen(vcl_boot/vgc.so) = vcl_boot/vgc.so: cannot open shared object > file: N > o such file or directory > Nov 30 23:30:44 www varnishd[16665]: Child (17228) ended > Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child starts > Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child dies > Nov 30 23:31:53 www named[2444]: error (network unreachable) resolving > 'www.amaz > on.it/A/IN': 2001:502:4612::1#53 > Nov 30 23:32:20 www varnishd[16665]: Manager got SIGINT > Nov 30 23:32:24 www varnishd[18670]: Platform: > Linux,2.6.32-573.8.1.el6.x86_64,x > 86_64,-junix,-smalloc,-smalloc,-hcritbit > Nov 30 23:32:24 www varnishd[18670]: child (18672) Started > Nov 30 23:32:24 www varnishd[18670]: Child (18672) said Child starts > Nov 30 23:32:51 www varnishd[18670]: Manager got SIGINT > Nov 30 23:32:52 www varnishd[18670]: Child (18672) ended > Nov 30 23:32:52 www varnishd[18670]: Child (18672) said Child die > }}} > > All my sites are currently down, the only solution I have for the > moment is to downgrade to 4.0 from 4.1.0-1. I tested the downgrade > and the service and my sites came right online once the downgrade was > complete. I would like to keep updated. New description: I upgraded via the CentOS package manager using the official repo from v4 to v4.1, had a small issue which I got fixed and everything was working fine. I needed to restart the varnish service yesterday and now it shows started but when I check the status of varnish or go to a web site hosted on the server the service shows not started and I cannot access any of my sites. I was able to get the access log going again, but I cannot figure out how to get the log going showing varnish startup/service errors or the success messages when it goes to start so all I have is the log info from messages which is: {{{ Nov 30 23:30:42 www varnishd[16665]: Child (16667) not responding to CLI, killin g it. Nov 30 23:30:42 www varnishd[16665]: Child (16667) died signal=11 (core dumped) Nov 30 23:30:42 www varnishd[16665]: Child (16667) Panic message: Assert error in child_sigsegv_handler(), mgt/mgt_child.c line 297: Condition(Segmentation fault by instruction at 0x205970) not true. thread = (cache-worker) version = varnish-4.1.0 revision 3041728 ident = Linux,2.6.32-573.8.1.el6.x86_64,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x432483: varnishd() [0x432483] 0x450de9: varnishd() [0x450de9] 0x34a480f790: libpthread.so.0() [0x34a480f790] 0x43c2b9: varnishd(VCL_DefaultDirector+0x19) [0x43c2b9] 0x436b9e: varnishd(CNT_Request+0x74e) [0x436b9e] 0x44cc3b: varnishd(HTTP1_Session+0x11b) [0x44cc3b] 0x439921: varnishd(SES_Proto_Req+0x61) [0x439921] 0x447aed: varnishd() [0x447aed] 0x447eeb: varnishd() [0x447eeb] 0x34a4807a51: libpthread.so.0() [0x34a4807a51] req = 0x7fe026896020 { vxid = 2, step = R_STP_RECV, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7fe02640f420 { fd = 13, vxid = 1, client = 180.76.15.6 56796, step = S_STP_H1PROC, }, worker = 0x7fe02d7eebc0 { stack = {0x7fe02d7ef000 -> 0x7fe02d7e3000}, ws = 0x7fe02d7eedb8 { id = "wrk", {s,f,r,e} = {0x7fe02d7ee380,0x7fe02d7ee380,(nil),+2040}, }, VCL::method = none, ws = 0x7fe026896200 { id = "req", {s,f,r,e} = {0x7fe026898000,+216,(nil),+57336}, }, http_conn = 0x7fe026896128 { fd = 13, doclose = NULL, ws = 0x7fe026896200, {rxbuf_b, rxbuf_e} = {0x7fe026898000, 0x7fe0268980b8}, {pipeline_b, pipeline_e} = {(nil), (nil)}, content_length = -1, body_status = none, first_byte_timeout = 0.000000, between_bytes_timeout = 0.000000, }, http[req] = 0x7fe026896298 { ws[req] = 0x7fe026896200, hdrs { "GET", "/", "HTTP/1.1", "Host: wsww", "Accept-Lang Nov 30 23:30:42 www varnishd[16665]: child (17228) Started Nov 30 23:30:43 www varnishd[16665]: Pushing vcls failed: Could not load compiled VCL. #011dlopen(vcl_boot/vgc.so) = vcl_boot/vgc.so: cannot open shared object file: No such file or directory Nov 30 23:30:44 www varnishd[16665]: Child (17228) ended Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child starts Nov 30 23:30:44 www varnishd[16665]: Child (17228) said Child dies Nov 30 23:31:53 www named[2444]: error (network unreachable) resolving 'www.amaz on.it/A/IN': 2001:502:4612::1#53 Nov 30 23:32:20 www varnishd[16665]: Manager got SIGINT Nov 30 23:32:24 www varnishd[18670]: Platform: Linux,2.6.32-573.8.1.el6.x86_64,x 86_64,-junix,-smalloc,-smalloc,-hcritbit Nov 30 23:32:24 www varnishd[18670]: child (18672) Started Nov 30 23:32:24 www varnishd[18670]: Child (18672) said Child starts Nov 30 23:32:51 www varnishd[18670]: Manager got SIGINT Nov 30 23:32:52 www varnishd[18670]: Child (18672) ended Nov 30 23:32:52 www varnishd[18670]: Child (18672) said Child die }}} All my sites are currently down, the only solution I have for the moment is to downgrade to 4.0 from 4.1.0-1. I tested the downgrade and the service and my sites came right online once the downgrade was complete. I would like to keep updated. -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 2 10:37:11 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Dec 2015 10:37:11 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 Message-ID: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+-------------------- Reporter: xrowkristina | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 4.1.0 | Severity: normal Keywords: | --------------------------+-------------------- Hey guys, there is a bug in varnish if a response is sending 204 without a body. Look at this http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html, in case of 204 a body is not allowed. Here is an example request without varnish: {{{ [11:11:24] root at webxyz.de # curl 'http://localhost/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I }}} '''Response:''' {{{ HTTP/1.1 204 No Content Date: Fri, 06 Nov 2015 10:11:51 GMT Server: Apache/2.4.7 (Ubuntu) X-Powered-By: PHP/5.5.9-1ubuntu4.9 Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 X-Cache-Debug: 1 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 }}} Here is the same request with varnish: {{{ [11:11:24] root at webxyz.de # curl 'http://kundenkonto- test.wuv.de/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I }}} '''Response:''' {{{ HTTP/1.1 503 Backend fetch failed Date: Fri, 06 Nov 2015 10:12:26 GMT Age: 0 X-Powered-By: xrow GmbH X-Cache: wuvtest-web-1:MISS:Grace:none:TTL:-52924.482:User- Hash:b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb Connection: keep-alive Set-Cookie: wuv-p=1678581420.49431.0000; path=/ }}} And here is the varnishlog to the second request: * << BeReq >> 134065 - Begin bereq 134064 fetch - Timestamp Start: 1446807850.981084 0.000000 0.000000 - BereqMethod HEAD - BereqURL /sso/linksubscription?abonummer=324223424242324&access_token=NDZhMDU5NTU5Y2E3MzgwZTg4YTQwODViZTI4ZTUwZDVmOTcyNGIwMWJkYjNmNDVjMzFiZDkwY2YyMjkxOTY5ZA - BereqProtocol HTTP/1.1 - BereqHeader User-Agent: curl/7.35.0 - BereqHeader Pragma: no-cache - BereqHeader X-Forwarded-For: 10.111.120.28, 10.111.120.28 - BereqHeader X-TTL: 247.535 - BereqHeader X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb - BereqHeader X-grace: none - BereqHeader Host: kundenkonto-test.wuv.de - BereqHeader Surrogate-Capability: abc=ESI/1.0 - BereqHeader accept: */* - BereqHeader cookie: eZSESSID=o2dumlbgq09e4g0sotinkevo71; - BereqMethod GET - BereqHeader Accept-Encoding: gzip - BereqHeader X-Varnish: 134065 - VCL_call BACKEND_FETCH - VCL_return fetch - BackendOpen 18 boot.default1 127.0.0.1 80 127.0.0.1 32876 - Timestamp Bereq: 1446807850.981164 0.000081 0.000081 - Timestamp Beresp: 1446807853.044470 2.063386 2.063306 - BerespProtocol HTTP/1.1 - BerespStatus 204 - BerespReason No Content - BerespHeader Date: Fri, 06 Nov 2015 11:04:10 GMT - BerespHeader Server: Apache/2.4.7 (Ubuntu) - BerespHeader X-Powered-By: PHP/5.5.9-1ubuntu4.9 - BerespHeader Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 - BerespHeader Vary: X-User-Hash - BerespHeader Content-Length: 0 - BerespHeader Content-Type: text/html; charset=utf-8 - BackendClose 18 boot.default1 - Error Body cannot be fetched - Timestamp Error: 1446807853.044513 2.063429 0.000043 - BerespProtocol HTTP/1.1 - BerespStatus 503 - BerespReason Service Unavailable - BerespReason Backend fetch failed - BerespHeader Date: Fri, 06 Nov 2015 11:04:13 GMT - BerespHeader Server: Varnish - VCL_call BACKEND_ERROR - VCL_return deliver - Storage malloc Transient - ObjProtocol HTTP/1.1 - ObjStatus 503 - ObjReason Backend fetch failed - ObjHeader Date: Fri, 06 Nov 2015 11:04:13 GMT - ObjHeader Server: Varnish - Length 0 - BereqAcct 531 0 531 272 0 272 - End This guy has also the same problem: http://www.gossamer- threads.com/lists/varnish/misc/37386?page=last Thanks for help Best regards Kristina -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 2 10:57:34 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Dec 2015 10:57:34 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.bbabfb9bf664d64ce3aee11633303c8b@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+-------------------- Reporter: xrowkristina | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: Keywords: | --------------------------+-------------------- Description changed by aondio: Old description: > Hey guys, > > there is a bug in varnish if a response is sending 204 without a body. > Look at this http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html, in > case of 204 a body is not allowed. > > Here is an example request without varnish: > > {{{ > [11:11:24] root at webxyz.de # curl > 'http://localhost/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' > -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: > eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H > 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I > }}} > > '''Response:''' > > {{{ > HTTP/1.1 204 No Content > Date: Fri, 06 Nov 2015 10:11:51 GMT > Server: Apache/2.4.7 (Ubuntu) > X-Powered-By: PHP/5.5.9-1ubuntu4.9 > Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 > X-Cache-Debug: 1 > Keep-Alive: timeout=5, max=100 > Connection: Keep-Alive > Content-Type: text/html; charset=utf-8 > }}} > > Here is the same request with varnish: > > {{{ > [11:11:24] root at webxyz.de # curl 'http://kundenkonto- > test.wuv.de/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' > -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: > eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H > 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I > }}} > > '''Response:''' > > {{{ > HTTP/1.1 503 Backend fetch failed > Date: Fri, 06 Nov 2015 10:12:26 GMT > Age: 0 > X-Powered-By: xrow GmbH > X-Cache: wuvtest-web-1:MISS:Grace:none:TTL:-52924.482:User- > Hash:b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb > Connection: keep-alive > Set-Cookie: wuv-p=1678581420.49431.0000; path=/ > }}} > > And here is the varnishlog to the second request: > > * << BeReq >> 134065 > > - Begin bereq 134064 fetch > > - Timestamp Start: 1446807850.981084 0.000000 0.000000 > > - BereqMethod HEAD > > - BereqURL > /sso/linksubscription?abonummer=324223424242324&access_token=NDZhMDU5NTU5Y2E3MzgwZTg4YTQwODViZTI4ZTUwZDVmOTcyNGIwMWJkYjNmNDVjMzFiZDkwY2YyMjkxOTY5ZA > > - BereqProtocol HTTP/1.1 > > - BereqHeader User-Agent: curl/7.35.0 > > - BereqHeader Pragma: no-cache > > - BereqHeader X-Forwarded-For: 10.111.120.28, 10.111.120.28 > > - BereqHeader X-TTL: 247.535 > > - BereqHeader X-User-Hash: > b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb > > - BereqHeader X-grace: none > > - BereqHeader Host: kundenkonto-test.wuv.de > > - BereqHeader Surrogate-Capability: abc=ESI/1.0 > > - BereqHeader accept: */* > > - BereqHeader cookie: eZSESSID=o2dumlbgq09e4g0sotinkevo71; > > - BereqMethod GET > > - BereqHeader Accept-Encoding: gzip > > - BereqHeader X-Varnish: 134065 > > - VCL_call BACKEND_FETCH > > - VCL_return fetch > > - BackendOpen 18 boot.default1 127.0.0.1 80 127.0.0.1 32876 > > - Timestamp Bereq: 1446807850.981164 0.000081 0.000081 > > - Timestamp Beresp: 1446807853.044470 2.063386 2.063306 > > - BerespProtocol HTTP/1.1 > > - BerespStatus 204 > > - BerespReason No Content > > - BerespHeader Date: Fri, 06 Nov 2015 11:04:10 GMT > > - BerespHeader Server: Apache/2.4.7 (Ubuntu) > > - BerespHeader X-Powered-By: PHP/5.5.9-1ubuntu4.9 > > - BerespHeader Cache-Control: max-age=0, must-revalidate, public, > s-maxage=0 > > - BerespHeader Vary: X-User-Hash > > - BerespHeader Content-Length: 0 > > - BerespHeader Content-Type: text/html; charset=utf-8 > > - BackendClose 18 boot.default1 > > - Error Body cannot be fetched > > - Timestamp Error: 1446807853.044513 2.063429 0.000043 > > - BerespProtocol HTTP/1.1 > > - BerespStatus 503 > > - BerespReason Service Unavailable > > - BerespReason Backend fetch failed > > - BerespHeader Date: Fri, 06 Nov 2015 11:04:13 GMT > > - BerespHeader Server: Varnish > > - VCL_call BACKEND_ERROR > > - VCL_return deliver > > - Storage malloc Transient > > - ObjProtocol HTTP/1.1 > > - ObjStatus 503 > > - ObjReason Backend fetch failed > > - ObjHeader Date: Fri, 06 Nov 2015 11:04:13 GMT > > - ObjHeader Server: Varnish > > - Length 0 > > - BereqAcct 531 0 531 272 0 272 > > - End > > This guy has also the same problem: http://www.gossamer- > threads.com/lists/varnish/misc/37386?page=last > > Thanks for help > > Best regards > Kristina New description: Hey guys, there is a bug in varnish if a response is sending 204 without a body. Look at this http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html, in case of 204 a body is not allowed. Here is an example request without varnish: {{{ [11:11:24] root at webxyz.de # curl 'http://localhost/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I }}} '''Response:''' {{{ HTTP/1.1 204 No Content Date: Fri, 06 Nov 2015 10:11:51 GMT Server: Apache/2.4.7 (Ubuntu) X-Powered-By: PHP/5.5.9-1ubuntu4.9 Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 X-Cache-Debug: 1 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 }}} Here is the same request with varnish: {{{ [11:11:24] root at webxyz.de # curl 'http://kundenkonto- test.wuv.de/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I }}} '''Response:''' {{{ HTTP/1.1 503 Backend fetch failed Date: Fri, 06 Nov 2015 10:12:26 GMT Age: 0 X-Powered-By: xrow GmbH X-Cache: wuvtest-web-1:MISS:Grace:none:TTL:-52924.482:User- Hash:b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb Connection: keep-alive Set-Cookie: wuv-p=1678581420.49431.0000; path=/ }}} And here is the varnishlog to the second request: {{{ * << BeReq >> 134065 - Begin bereq 134064 fetch - Timestamp Start: 1446807850.981084 0.000000 0.000000 - BereqMethod HEAD - BereqURL /sso/linksubscription?abonummer=324223424242324&access_token=NDZhMDU5NTU5Y2E3MzgwZTg4YTQwODViZTI4ZTUwZDVmOTcyNGIwMWJkYjNmNDVjMzFiZDkwY2YyMjkxOTY5ZA - BereqProtocol HTTP/1.1 - BereqHeader User-Agent: curl/7.35.0 - BereqHeader Pragma: no-cache - BereqHeader X-Forwarded-For: 10.111.120.28, 10.111.120.28 - BereqHeader X-TTL: 247.535 - BereqHeader X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb - BereqHeader X-grace: none - BereqHeader Host: kundenkonto-test.wuv.de - BereqHeader Surrogate-Capability: abc=ESI/1.0 - BereqHeader accept: */* - BereqHeader cookie: eZSESSID=o2dumlbgq09e4g0sotinkevo71; - BereqMethod GET - BereqHeader Accept-Encoding: gzip - BereqHeader X-Varnish: 134065 - VCL_call BACKEND_FETCH - VCL_return fetch - BackendOpen 18 boot.default1 127.0.0.1 80 127.0.0.1 32876 - Timestamp Bereq: 1446807850.981164 0.000081 0.000081 - Timestamp Beresp: 1446807853.044470 2.063386 2.063306 - BerespProtocol HTTP/1.1 - BerespStatus 204 - BerespReason No Content - BerespHeader Date: Fri, 06 Nov 2015 11:04:10 GMT - BerespHeader Server: Apache/2.4.7 (Ubuntu) - BerespHeader X-Powered-By: PHP/5.5.9-1ubuntu4.9 - BerespHeader Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 - BerespHeader Vary: X-User-Hash - BerespHeader Content-Length: 0 - BerespHeader Content-Type: text/html; charset=utf-8 - BackendClose 18 boot.default1 - Error Body cannot be fetched - Timestamp Error: 1446807853.044513 2.063429 0.000043 - BerespProtocol HTTP/1.1 - BerespStatus 503 - BerespReason Service Unavailable - BerespReason Backend fetch failed - BerespHeader Date: Fri, 06 Nov 2015 11:04:13 GMT - BerespHeader Server: Varnish - VCL_call BACKEND_ERROR - VCL_return deliver - Storage malloc Transient - ObjProtocol HTTP/1.1 - ObjStatus 503 - ObjReason Backend fetch failed - ObjHeader Date: Fri, 06 Nov 2015 11:04:13 GMT - ObjHeader Server: Varnish - Length 0 - BereqAcct 531 0 531 272 0 272 - End }}} This guy has also the same problem: http://www.gossamer- threads.com/lists/varnish/misc/37386?page=last Thanks for help Best regards Kristina -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 2 10:58:48 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Dec 2015 10:58:48 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.c36e1f7f324646cc985a6546bb5cd2a7@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+-------------------- Reporter: xrowkristina | Owner: Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: Keywords: | --------------------------+-------------------- Description changed by aondio: Old description: > Hey guys, > > there is a bug in varnish if a response is sending 204 without a body. > Look at this http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html, in > case of 204 a body is not allowed. > > Here is an example request without varnish: > > {{{ > [11:11:24] root at webxyz.de # curl > 'http://localhost/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' > -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: > eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H > 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I > }}} > > '''Response:''' > > {{{ > HTTP/1.1 204 No Content > Date: Fri, 06 Nov 2015 10:11:51 GMT > Server: Apache/2.4.7 (Ubuntu) > X-Powered-By: PHP/5.5.9-1ubuntu4.9 > Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 > X-Cache-Debug: 1 > Keep-Alive: timeout=5, max=100 > Connection: Keep-Alive > Content-Type: text/html; charset=utf-8 > }}} > > Here is the same request with varnish: > > {{{ > [11:11:24] root at webxyz.de # curl 'http://kundenkonto- > test.wuv.de/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' > -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: > eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H > 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I > }}} > > '''Response:''' > > {{{ > HTTP/1.1 503 Backend fetch failed > Date: Fri, 06 Nov 2015 10:12:26 GMT > Age: 0 > X-Powered-By: xrow GmbH > X-Cache: wuvtest-web-1:MISS:Grace:none:TTL:-52924.482:User- > Hash:b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb > Connection: keep-alive > Set-Cookie: wuv-p=1678581420.49431.0000; path=/ > }}} > > And here is the varnishlog to the second request: > > {{{ > * << BeReq >> 134065 > - Begin bereq 134064 fetch > > - Timestamp Start: 1446807850.981084 0.000000 0.000000 > > - BereqMethod HEAD > > - BereqURL > /sso/linksubscription?abonummer=324223424242324&access_token=NDZhMDU5NTU5Y2E3MzgwZTg4YTQwODViZTI4ZTUwZDVmOTcyNGIwMWJkYjNmNDVjMzFiZDkwY2YyMjkxOTY5ZA > > - BereqProtocol HTTP/1.1 > > - BereqHeader User-Agent: curl/7.35.0 > > - BereqHeader Pragma: no-cache > > - BereqHeader X-Forwarded-For: 10.111.120.28, 10.111.120.28 > > - BereqHeader X-TTL: 247.535 > > - BereqHeader X-User-Hash: > b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb > > - BereqHeader X-grace: none > > - BereqHeader Host: kundenkonto-test.wuv.de > > - BereqHeader Surrogate-Capability: abc=ESI/1.0 > > - BereqHeader accept: */* > > - BereqHeader cookie: eZSESSID=o2dumlbgq09e4g0sotinkevo71; > > - BereqMethod GET > > - BereqHeader Accept-Encoding: gzip > > - BereqHeader X-Varnish: 134065 > > - VCL_call BACKEND_FETCH > > - VCL_return fetch > > - BackendOpen 18 boot.default1 127.0.0.1 80 127.0.0.1 32876 > > - Timestamp Bereq: 1446807850.981164 0.000081 0.000081 > > - Timestamp Beresp: 1446807853.044470 2.063386 2.063306 > > - BerespProtocol HTTP/1.1 > > - BerespStatus 204 > > - BerespReason No Content > > - BerespHeader Date: Fri, 06 Nov 2015 11:04:10 GMT > > - BerespHeader Server: Apache/2.4.7 (Ubuntu) > > - BerespHeader X-Powered-By: PHP/5.5.9-1ubuntu4.9 > > - BerespHeader Cache-Control: max-age=0, must-revalidate, public, > s-maxage=0 > > - BerespHeader Vary: X-User-Hash > > - BerespHeader Content-Length: 0 > > - BerespHeader Content-Type: text/html; charset=utf-8 > > - BackendClose 18 boot.default1 > > - Error Body cannot be fetched > > - Timestamp Error: 1446807853.044513 2.063429 0.000043 > > - BerespProtocol HTTP/1.1 > > - BerespStatus 503 > > - BerespReason Service Unavailable > > - BerespReason Backend fetch failed > > - BerespHeader Date: Fri, 06 Nov 2015 11:04:13 GMT > > - BerespHeader Server: Varnish > > - VCL_call BACKEND_ERROR > > - VCL_return deliver > > - Storage malloc Transient > > - ObjProtocol HTTP/1.1 > > - ObjStatus 503 > > - ObjReason Backend fetch failed > > - ObjHeader Date: Fri, 06 Nov 2015 11:04:13 GMT > > - ObjHeader Server: Varnish > > - Length 0 > > - BereqAcct 531 0 531 272 0 272 > > - End > }}} > > This guy has also the same problem: http://www.gossamer- > threads.com/lists/varnish/misc/37386?page=last > > Thanks for help > > Best regards > Kristina New description: Hey guys, there is a bug in varnish if a response is sending 204 without a body. Look at this http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html, in case of 204 a body is not allowed. Here is an example request without varnish: {{{ [11:11:24] root at webxyz.de # curl 'http://localhost/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I }}} '''Response:''' {{{ HTTP/1.1 204 No Content Date: Fri, 06 Nov 2015 10:11:51 GMT Server: Apache/2.4.7 (Ubuntu) X-Powered-By: PHP/5.5.9-1ubuntu4.9 Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 X-Cache-Debug: 1 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 }}} Here is the same request with varnish: {{{ [11:11:24] root at webxyz.de # curl 'http://kundenkonto- test.wuv.de/sso/linksubscription?access_token=MmRkYWNmNTY0NTJhZTFhMjNiMjExNGI1MGMyMzcxZmEzMjg0ZmI0YTZmMjJhYzZiMDJmMmUxMjlmMTFlNjVmYg&abonummer=324223424242324' -H 'Host: kundenkonto-test.wuv.de' -H 'Cookie: eZSESSID=bgocrn0dk4uaibnknlu7n46ht7;' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -I }}} '''Response:''' {{{ HTTP/1.1 503 Backend fetch failed Date: Fri, 06 Nov 2015 10:12:26 GMT Age: 0 X-Powered-By: xrow GmbH X-Cache: wuvtest-web-1:MISS:Grace:none:TTL:-52924.482:User- Hash:b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb Connection: keep-alive Set-Cookie: wuv-p=1678581420.49431.0000; path=/ }}} And here is the varnishlog to the second request: {{{ * << BeReq >> 134065 - Begin bereq 134064 fetch - Timestamp Start: 1446807850.981084 0.000000 0.000000 - BereqMethod HEAD - BereqURL /sso/linksubscription?abonummer=324223424242324&access_token=NDZhMDU5NTU5Y2E3MzgwZTg4YTQwODViZTI4ZTUwZDVmOTcyNGIwMWJkYjNmNDVjMzFiZDkwY2YyMjkxOTY5ZA - BereqProtocol HTTP/1.1 - BereqHeader User-Agent: curl/7.35.0 - BereqHeader Pragma: no-cache - BereqHeader X-Forwarded-For: 10.111.120.28, 10.111.120.28 - BereqHeader X-TTL: 247.535 - BereqHeader X-User-Hash: b1731d46b0e7a375a5b024e950fdb8d49dd25af85a5c7dd5116ad2a18cda82cb - BereqHeader X-grace: none - BereqHeader Host: kundenkonto-test.wuv.de - BereqHeader Surrogate-Capability: abc=ESI/1.0 - BereqHeader accept: */* - BereqHeader cookie: eZSESSID=o2dumlbgq09e4g0sotinkevo71; - BereqMethod GET - BereqHeader Accept-Encoding: gzip - BereqHeader X-Varnish: 134065 - VCL_call BACKEND_FETCH - VCL_return fetch - BackendOpen 18 boot.default1 127.0.0.1 80 127.0.0.1 32876 - Timestamp Bereq: 1446807850.981164 0.000081 0.000081 - Timestamp Beresp: 1446807853.044470 2.063386 2.063306 - BerespProtocol HTTP/1.1 - BerespStatus 204 - BerespReason No Content - BerespHeader Date: Fri, 06 Nov 2015 11:04:10 GMT - BerespHeader Server: Apache/2.4.7 (Ubuntu) - BerespHeader X-Powered-By: PHP/5.5.9-1ubuntu4.9 - BerespHeader Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 - BerespHeader Vary: X-User-Hash - BerespHeader Content-Length: 0 - BerespHeader Content-Type: text/html; charset=utf-8 - BackendClose 18 boot.default1 - Error Body cannot be fetched - Timestamp Error: 1446807853.044513 2.063429 0.000043 - BerespProtocol HTTP/1.1 - BerespStatus 503 - BerespReason Service Unavailable - BerespReason Backend fetch failed - BerespHeader Date: Fri, 06 Nov 2015 11:04:13 GMT - BerespHeader Server: Varnish - VCL_call BACKEND_ERROR - VCL_return deliver - Storage malloc Transient - ObjProtocol HTTP/1.1 - ObjStatus 503 - ObjReason Backend fetch failed - ObjHeader Date: Fri, 06 Nov 2015 11:04:13 GMT - ObjHeader Server: Varnish - Length 0 - BereqAcct 531 0 531 272 0 272 - End }}} This guy has also the same problem: http://www.gossamer- threads.com/lists/varnish/misc/37386?page=last Thanks for help Best regards Kristina -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 2 17:28:12 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 02 Dec 2015 17:28:12 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.dddd9fa187b5b420a84c2eaf77c77bc9@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+---------------------- Reporter: xrowkristina | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Changes (by fgsch): * status: new => closed * resolution: => invalid Comment: Your backend is returning a Content-Length. This is invalid for 204 responses. As per rfc7230 3.3.2 p31: {{{ A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [RFC7231]). }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 3 13:16:07 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 03 Dec 2015 13:16:07 -0000 Subject: [Varnish] #1827: Fetch no body from backend when using HTTP/1.0 and Beresp is uncacheable Message-ID: <046.cc50d6b17b84c5cff08ffeb40a77e2b5@varnish-cache.org> #1827: Fetch no body from backend when using HTTP/1.0 and Beresp is uncacheable ----------------------+-------------------- Reporter: jparedes | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 4.1.0 | Severity: normal Keywords: | ----------------------+-------------------- I'm caching requests that originate from an nginx v1.8.0 balancer which happen to default to HTTP/1.0 for proxying. When Varnish hits an app node (nginx v1.8.0) and the response is uncacheable (has a Set-Cookie header, or Expire: -1) Varnish returns no body. This started to happen as soon as i upgraded from 4.0 to 4.1. I'm using varnish-4.1.0(revision 3041728) adding just as little as the backend definition to the default vcl. From the app server perspective seems Varnish is dropping the connection early. Switching requests to HTTP/1.1 from balancer seems to fix this issue, but i'm curious about what's happening behind the scenes. '''VLC config''' {{{ vcl 4.0; backend default { .host = "127.0.0.1"; .port = "80"; } }}} '''varnishlog''' {{{ * << Session >> 32795 - Begin sess 0 HTTP/1 - SessOpen 127.0.0.1 32872 :81 127.0.0.1 81 1449147365.342063 15 - Link req 32796 rxreq - SessClose RESP_CLOSE 0.294 - End * << BeReq >> 32800 - Begin bereq 32799 fetch - Timestamp Start: 1449147372.327667 0.000000 0.000000 - BereqMethod GET - BereqURL /sitios/conectados/inicio/ - BereqProtocol HTTP/1.0 - BereqHeader Host: local.conectados.gob.ar - BereqHeader X-Real-IP: 127.0.0.1 - BereqHeader User-Agent: curl/7.35.0 - BereqHeader Accept: */* - BereqHeader X-Forwarded-For: 127.0.0.1 - BereqProtocol HTTP/1.1 - BereqHeader Accept-Encoding: gzip - BereqHeader X-Varnish: 32800 - VCL_call BACKEND_FETCH - VCL_return fetch - BackendOpen 18 boot.default 127.0.0.1 80 127.0.0.1 38847 - Timestamp Bereq: 1449147372.327824 0.000156 0.000156 - Timestamp Beresp: 1449147372.597840 0.270173 0.270016 - BerespProtocol HTTP/1.1 - BerespStatus 200 - BerespReason OK - BerespHeader Server: nginx/1.8.0 - BerespHeader Date: Thu, 03 Dec 2015 12:56:12 GMT - BerespHeader Content-Type: text/html - BerespHeader Transfer-Encoding: chunked - BerespHeader Connection: keep-alive - BerespHeader X-Powered-By: PHP/5.5.9-1ubuntu4.14 - TTL RFC 120 10 -1 1449147373 1449147373 1449147372 0 0 - VCL_call BACKEND_RESPONSE - VCL_return deliver - Storage malloc s0 - ObjProtocol HTTP/1.1 - ObjStatus 200 - ObjReason OK - ObjHeader Server: nginx/1.8.0 - ObjHeader Date: Thu, 03 Dec 2015 12:56:12 GMT - ObjHeader Content-Type: text/html - ObjHeader X-Powered-By: PHP/5.5.9-1ubuntu4.14 - Fetch_Body 2 chunked stream - BackendReuse 18 boot.default - Timestamp BerespBody: 1449147372.599237 0.271570 0.001397 - Length 45187 - BereqAcct 203 0 203 191 45187 45378 - End * << Request >> 32799 - Begin req 32798 rxreq - Timestamp Start: 1449147372.327589 0.000000 0.000000 - Timestamp Req: 1449147372.327589 0.000000 0.000000 - ReqStart 127.0.0.1 32881 - ReqMethod GET - ReqURL /sitios/conectados/inicio/ - ReqProtocol HTTP/1.0 - ReqHeader Host: local.conectados.gob.ar - ReqHeader X-Real-IP: 127.0.0.1 - ReqHeader Connection: close - ReqHeader User-Agent: curl/7.35.0 - ReqHeader Accept: */* - ReqHeader X-Forwarded-For: 127.0.0.1 - VCL_call RECV - VCL_return hash - VCL_call HASH - VCL_return lookup - VCL_call MISS - VCL_return fetch - Link bereq 32800 fetch - Timestamp Fetch: 1449147372.597970 0.270381 0.270381 - RespProtocol HTTP/1.1 - RespStatus 200 - RespReason OK - RespHeader Server: nginx/1.8.0 - RespHeader Date: Thu, 03 Dec 2015 12:56:12 GMT - RespHeader Content-Type: text/html - RespHeader X-Powered-By: PHP/5.5.9-1ubuntu4.14 - RespHeader X-Varnish: 32799 - RespHeader Age: 0 - RespHeader Via: 1.1 varnish-v4 - VCL_call DELIVER - VCL_return deliver - Timestamp Process: 1449147372.597987 0.270398 0.000017 - RespHeader Accept-Ranges: bytes - Debug "RES_MODE 4" - RespHeader Connection: close - Timestamp Resp: 1449147372.599283 0.271693 0.001295 - ReqAcct 153 0 153 227 45187 45414 - End * << Session >> 32798 - Begin sess 0 HTTP/1 - SessOpen 127.0.0.1 32881 :81 127.0.0.1 81 1449147372.327418 16 - Link req 32799 rxreq - SessClose RESP_CLOSE 0.272 - End }}} '''Nginx app server log''': {{{ 2015/12/03 10:10:09 [debug] 5807#0: *158 http header: "Host: local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 http header: "X-Real-IP: 127.0.0.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 http header: "User-Agent: curl/7.35.0" 2015/12/03 10:10:09 [debug] 5807#0: *158 http header: "Accept: */*" 2015/12/03 10:10:09 [debug] 5807#0: *158 http header: "cookie: login_token=1" 2015/12/03 10:10:09 [debug] 5807#0: *158 http header: "X-Forwarded-For: 127.0.0.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 http header: "X-Varnish: 47" 2015/12/03 10:10:09 [debug] 5807#0: *158 http header done 2015/12/03 10:10:09 [debug] 5807#0: *158 event timer del: 19: 1449148269446 2015/12/03 10:10:09 [debug] 5807#0: *158 generic phase: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 rewrite phase: 1 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: "/" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: "concursos" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: "vendor" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: "usuario" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: ~ "(.+\.txt)$" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: ~ "^/js/yui(/?)(.*)$" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: ~ "\.php$" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: ~ "^(/?|/404/?|/video(/?|/.*)|/audio(/?|/.*)|/enlace(/?|/.*)|/foto(/?|/.*)|/nota(/?|/.*)|/archivo(/?|/.*))$" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: ~ "^/rest/(.*)$" 2015/12/03 10:10:09 [debug] 5807#0: *158 using configuration "/" 2015/12/03 10:10:09 [debug] 5807#0: *158 http cl:-1 max:20971520 2015/12/03 10:10:09 [debug] 5807#0: *158 rewrite phase: 3 2015/12/03 10:10:09 [debug] 5807#0: *158 http script complex value 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "/media/repository/work/webapps/conectados_git/webroot/sitios/conectados/inicio/" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script file op 0000000000000003 "/media/repository/work/webapps/conectados_git/webroot/sitios/conectados/inicio/" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script if 2015/12/03 10:10:09 [debug] 5807#0: *158 http script complex value 2015/12/03 10:10:09 [warn] 5807#0: *158 using uninitialized "rule_0" variable, client: 127.0.0.1, server: local.conectados.gob.ar, request: "GET /sitios/conectados/inicio/ HTTP/1.0", host: "local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "1" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script set $rule_0 2015/12/03 10:10:09 [debug] 5807#0: *158 http script complex value 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "/media/repository/work/webapps/conectados_git/webroot/sitios/conectados/inicio/" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script file op 0000000000000001 "/media/repository/work/webapps/conectados_git/webroot/sitios/conectados/inicio/" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script if 2015/12/03 10:10:09 [debug] 5807#0: *158 http script complex value 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "2" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "1" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script set $rule_0 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "21" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script value: "21" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script equal 2015/12/03 10:10:09 [debug] 5807#0: *158 http script if 2015/12/03 10:10:09 [debug] 5807#0: *158 http script regex: "^/(.*)$" 2015/12/03 10:10:09 [notice] 5807#0: *158 "^/(.*)$" matches "/sitios/conectados/inicio/", client: 127.0.0.1, server: local.conectados.gob.ar, request: "GET /sitios/conectados/inicio/ HTTP/1.0", host: "local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "/index.php" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script args 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "r=" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script capture: "sitios/conectados/inicio/" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script regex end 2015/12/03 10:10:09 [notice] 5807#0: *158 rewritten data: "/index.php", args: "r=sitios/conectados/inicio/&", client: 127.0.0.1, server: local.conectados.gob.ar, request: "GET /sitios/conectados/inicio/ HTTP/1.0", host: "local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 post rewrite phase: 4 2015/12/03 10:10:09 [debug] 5807#0: *158 uri changes: 11 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: "/" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: "concursos" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: "vendor" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: "usuario" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: ~ "(.+\.txt)$" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: ~ "^/js/yui(/?)(.*)$" 2015/12/03 10:10:09 [debug] 5807#0: *158 test location: ~ "\.php$" 2015/12/03 10:10:09 [debug] 5807#0: *158 using configuration "\.php$" 2015/12/03 10:10:09 [debug] 5807#0: *158 http cl:-1 max:20971520 2015/12/03 10:10:09 [debug] 5807#0: *158 rewrite phase: 3 2015/12/03 10:10:09 [debug] 5807#0: *158 post rewrite phase: 4 2015/12/03 10:10:09 [debug] 5807#0: *158 generic phase: 5 2015/12/03 10:10:09 [debug] 5807#0: *158 generic phase: 6 2015/12/03 10:10:09 [debug] 5807#0: *158 generic phase: 7 2015/12/03 10:10:09 [debug] 5807#0: *158 access phase: 8 2015/12/03 10:10:09 [debug] 5807#0: *158 access phase: 9 2015/12/03 10:10:09 [debug] 5807#0: *158 access phase: 10 2015/12/03 10:10:09 [debug] 5807#0: *158 post access phase: 11 2015/12/03 10:10:09 [debug] 5807#0: *158 try files phase: 12 2015/12/03 10:10:09 [debug] 5807#0: *158 http init upstream, client timer: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 epoll add event: fd:19 op:3 ev:80002005 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "QUERY_STRING" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "QUERY_STRING: r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "REQUEST_METHOD" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "GET" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "REQUEST_METHOD: GET" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "CONTENT_TYPE" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "CONTENT_TYPE: " 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "CONTENT_LENGTH" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "CONTENT_LENGTH: " 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "SCRIPT_NAME" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "/index.php" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "SCRIPT_NAME: /index.php" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "REQUEST_URI" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "/sitios/conectados/inicio/" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "REQUEST_URI: /sitios/conectados/inicio/" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "DOCUMENT_URI" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "/index.php" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "DOCUMENT_URI: /index.php" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "DOCUMENT_ROOT" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "/media/repository/work/webapps/conectados_git/webroot" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "DOCUMENT_ROOT: /media/repository/work/webapps/conectados_git/webroot" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "SERVER_PROTOCOL" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "HTTP/1.0" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "SERVER_PROTOCOL: HTTP/1.0" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "GATEWAY_INTERFACE" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "CGI/1.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "GATEWAY_INTERFACE: CGI/1.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "SERVER_SOFTWARE" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "nginx/" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "1.8.0" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "SERVER_SOFTWARE: nginx/1.8.0" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "REMOTE_ADDR" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "127.0.0.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "REMOTE_ADDR: 127.0.0.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "REMOTE_PORT" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "38891" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "REMOTE_PORT: 38891" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "SERVER_ADDR" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "127.0.0.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "SERVER_ADDR: 127.0.0.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "SERVER_PORT" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "80" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "SERVER_PORT: 80" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "SERVER_NAME" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "SERVER_NAME: local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "REDIRECT_STATUS" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "200" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "REDIRECT_STATUS: 200" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script copy: "SCRIPT_FILENAME" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "/media/repository/work/webapps/conectados_git/webroot" 2015/12/03 10:10:09 [debug] 5807#0: *158 http script var: "/index.php" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "SCRIPT_FILENAME: /media/repository/work/webapps/conectados_git/webroot/index.php" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "HTTP_HOST: local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "HTTP_X_REAL_IP: 127.0.0.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "HTTP_USER_AGENT: curl/7.35.0" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "HTTP_ACCEPT: */*" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "HTTP_COOKIE: login_token=1" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "HTTP_X_FORWARDED_FOR: 127.0.0.1" 2015/12/03 10:10:09 [debug] 5807#0: *158 fastcgi param: "HTTP_X_VARNISH: 47" 2015/12/03 10:10:09 [debug] 5807#0: *158 http cleanup add: 0000000000BB3CC8 2015/12/03 10:10:09 [debug] 5807#0: *158 get rr peer, try: 1 2015/12/03 10:10:09 [debug] 5807#0: *158 socket 20 2015/12/03 10:10:09 [debug] 5807#0: *158 epoll add connection: fd:20 ev:80002005 2015/12/03 10:10:09 [debug] 5807#0: *158 connect to unix:/var/run/php5-fpm.sock, fd:20 #159 2015/12/03 10:10:09 [debug] 5807#0: *158 connected 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream connect: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 posix_memalign: 0000000000C28130:128 @16 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream send request 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream send request body 2015/12/03 10:10:09 [debug] 5807#0: *158 chain writer buf fl:0 s:760 2015/12/03 10:10:09 [debug] 5807#0: *158 chain writer in: 0000000000BB3D00 2015/12/03 10:10:09 [debug] 5807#0: *158 writev: 760 of 760 2015/12/03 10:10:09 [debug] 5807#0: *158 chain writer out: 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 event timer add: 20: 150000:1449148359446 2015/12/03 10:10:09 [debug] 5807#0: *158 http finalize request: -4, "/index.php?r=sitios/conectados/inicio/&" a:1, c:2 2015/12/03 10:10:09 [debug] 5807#0: *158 http request count:2 blk:0 2015/12/03 10:10:09 [debug] 5807#0: *158 post event 0000000000C0F9E8 2015/12/03 10:10:09 [debug] 5807#0: *158 post event 0000000000C0FA50 2015/12/03 10:10:09 [debug] 5807#0: *158 delete posted event 0000000000C0F9E8 2015/12/03 10:10:09 [debug] 5807#0: *158 http run request: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream check client, write event:1, "/index.php" 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream recv(): -1 (11: Resource temporarily unavailable) 2015/12/03 10:10:09 [debug] 5807#0: *158 delete posted event 0000000000C0FA50 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream request: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream dummy handler 2015/12/03 10:10:09 [debug] 5807#0: *158 post event 0000000000BFC240 2015/12/03 10:10:09 [debug] 5807#0: *158 post event 0000000000C0FA50 2015/12/03 10:10:09 [debug] 5807#0: *158 delete posted event 0000000000BFC240 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream request: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream process header 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000BB3E90:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 posix_memalign: 0000000000CB4AC0:4096 @16 2015/12/03 10:10:09 [debug] 5807#0: *158 recv: fd:20 4096 of 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 01 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 06 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 01 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: BC 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 04 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record length: 188 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi parser: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi header: "X-Powered- By: PHP/5.5.9-1ubuntu4.14" 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi parser: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi header: "Set-Cookie: login_token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi parser: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi header: "Content- type: text/html" 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi parser: 1 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi header done 2015/12/03 10:10:09 [debug] 5807#0: *158 HTTP/1.1 200 OK Server: nginx/1.8.0 Date: Thu, 03 Dec 2015 13:10:09 GMT Content-Type: text/html Connection: close X-Powered-By: PHP/5.5.9-1ubuntu4.14 Set-Cookie: login_token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.local.conectados.gob.ar 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000CB4C60, pos 0000000000CB4C60, size: 282 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter: l:0 f:0 s:282 2015/12/03 10:10:09 [debug] 5807#0: *158 http cacheable: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream process upstream 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe read upstream: 1 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe preread: 3900 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 01 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 06 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 01 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: B0 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 80 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record length: 45184 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #0 0000000000BB3F60 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000BB3F60 3888 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000CB5AD0:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 1, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #1 0000000000CB5AD0 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000CB5AD0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000CB6AE0:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 1, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #2 0000000000CB6AE0 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000CB6AE0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000BCA2E0:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 1, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #3 0000000000BCA2E0 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000BCA2E0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000BCB2F0:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 1, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #4 0000000000BCB2F0 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000BCB2F0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000BCC300:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 1, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #5 0000000000BCC300 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000BCC300 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000C80990:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 1, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #6 0000000000C80990 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000C80990 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000C819A0:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 1, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #7 0000000000C819A0 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000C819A0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 malloc: 0000000000C829B0:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 1, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #8 0000000000C829B0 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000C829B0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe downstream ready 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000BB3E90, pos 0000000000BB3F60, size: 3888 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000CB5AD0, pos 0000000000CB5AD0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000CB6AE0, pos 0000000000CB6AE0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000BCA2E0, pos 0000000000BCA2E0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000BCB2F0, pos 0000000000BCB2F0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000BCC300, pos 0000000000BCC300, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000C80990, pos 0000000000C80990, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000C819A0, pos 0000000000C819A0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000C829B0, pos 0000000000C829B0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe length: -1 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write downstream: 1 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write busy: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000BB3F60 3888 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000CB5AD0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000CB6AE0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write: out:0000000000BB3E68, f:1 2015/12/03 10:10:09 [debug] 5807#0: *158 http output filter "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http postpone filter "/index.php?r=sitios/conectados/inicio/&" 0000000000BB3E58 2015/12/03 10:10:09 [debug] 5807#0: *158 write old buf t:1 f:0 0000000000CB4C60, pos 0000000000CB4C60, size: 282 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000BB3E90, pos 0000000000BB3F60, size: 3888 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000CB5AD0, pos 0000000000CB5AD0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter: l:0 f:1 s:8266 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter limit 0 2015/12/03 10:10:09 [debug] 5807#0: *158 writev: 8266 of 8266 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: 0 "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write busy: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000CB6AE0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000BCA2E0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000BCB2F0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write: out:0000000000CB4FF0, f:1 2015/12/03 10:10:09 [debug] 5807#0: *158 http output filter "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http postpone filter "/index.php?r=sitios/conectados/inicio/&" 0000000000CB5560 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000CB6AE0, pos 0000000000CB6AE0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000BCA2E0, pos 0000000000BCA2E0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter: l:0 f:1 s:8192 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter limit 0 2015/12/03 10:10:09 [debug] 5807#0: *158 writev: 8192 of 8192 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: 0 "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write busy: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000BCB2F0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000BCC300 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000C80990 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write: out:0000000000CB5170, f:1 2015/12/03 10:10:09 [debug] 5807#0: *158 http output filter "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http postpone filter "/index.php?r=sitios/conectados/inicio/&" 0000000000CB5570 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000BCB2F0, pos 0000000000BCB2F0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000BCC300, pos 0000000000BCC300, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter: l:0 f:1 s:8192 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter limit 0 2015/12/03 10:10:09 [debug] 5807#0: *158 writev: 8192 of 8192 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: 0 "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write busy: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000C80990 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000C819A0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write buf ls:1 0000000000C829B0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write: out:0000000000CB52F0, f:1 2015/12/03 10:10:09 [debug] 5807#0: *158 http output filter "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http postpone filter "/index.php?r=sitios/conectados/inicio/&" 0000000000CB5590 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000C80990, pos 0000000000C80990, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 write new buf t:1 f:0 0000000000C819A0, pos 0000000000C819A0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter: l:0 f:1 s:8192 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter limit 0 2015/12/03 10:10:09 [debug] 5807#0: *158 writev: -1 of 8192 2015/12/03 10:10:09 [info] 5807#0: *158 writev() failed (32: Broken pipe) while sending to client, client: 127.0.0.1, server: local.conectados.gob.ar, request: "GET /sitios/conectados/inicio/ HTTP/1.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "local.conectados.gob.ar" 2015/12/03 10:10:09 [debug] 5807#0: *158 http write filter FFFFFFFFFFFFFFFF 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: -1 "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe read upstream: 1 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 9, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 8560 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #9 0000000000C829B0 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000C829B0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #10 0000000000C819A0 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000C819A0 4096 2015/12/03 10:10:09 [debug] 5807#0: *158 readv: 7, last:4096 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe recv chain: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000C829B0, pos 0000000000C829B0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf in s:1 t:1 f:0 0000000000C819A0, pos 0000000000C819A0, size: 4096 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf free s:0 t:1 f:0 0000000000C80990, pos 0000000000C80990, size: 368 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf free s:0 t:1 f:0 0000000000BCB2F0, pos 0000000000BCB2F0, size: 0 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf free s:0 t:1 f:0 0000000000BCC300, pos 0000000000BCC300, size: 0 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf free s:0 t:1 f:0 0000000000CB6AE0, pos 0000000000CB6AE0, size: 0 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf free s:0 t:1 f:0 0000000000BCA2E0, pos 0000000000BCA2E0, size: 0 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf free s:0 t:1 f:0 0000000000BB3E90, pos 0000000000BB3E90, size: 0 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe buf free s:0 t:1 f:0 0000000000CB5AD0, pos 0000000000CB5AD0, size: 0 file: 0, size: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe length: -1 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #11 0000000000C80990 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 01 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 06 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 01 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 03 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 05 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record length: 3 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf #11 0000000000C80AE8 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 01 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 03 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 01 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 08 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record byte: 00 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi record length: 8 2015/12/03 10:10:09 [debug] 5807#0: *158 http fastcgi sent end request 2015/12/03 10:10:09 [debug] 5807#0: *158 input buf 0000000000C80AE8 3 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000BCB2F0 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000BCC300 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000CB6AE0 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000BCA2E0 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000BB3E90 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000CB5AD0 2015/12/03 10:10:09 [debug] 5807#0: *158 pipe write downstream: 1 2015/12/03 10:10:09 [debug] 5807#0: *158 event timer del: 20: 1449148359446 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream exit: 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 finalize http upstream request: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 finalize http fastcgi request 2015/12/03 10:10:09 [debug] 5807#0: *158 free rr peer 1 0 2015/12/03 10:10:09 [debug] 5807#0: *158 close http upstream connection: 20 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000C28130, unused: 48 2015/12/03 10:10:09 [debug] 5807#0: *158 delete posted event 0000000000C0FA50 2015/12/03 10:10:09 [debug] 5807#0: *158 reusable connection: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 http upstream temp fd: -1 2015/12/03 10:10:09 [debug] 5807#0: *158 http output filter "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http postpone filter "/index.php?r=sitios/conectados/inicio/&" 00007FFFF1C4E640 2015/12/03 10:10:09 [debug] 5807#0: *158 http copy filter: -1 "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http finalize request: -1, "/index.php?r=sitios/conectados/inicio/&" a:1, c:1 2015/12/03 10:10:09 [debug] 5807#0: *158 http terminate request count:1 2015/12/03 10:10:09 [debug] 5807#0: *158 http terminate cleanup count:1 blk:0 2015/12/03 10:10:09 [debug] 5807#0: *158 http posted request: "/index.php?r=sitios/conectados/inicio/&" 2015/12/03 10:10:09 [debug] 5807#0: *158 http terminate handler count:1 2015/12/03 10:10:09 [debug] 5807#0: *158 http request count:1 blk:0 2015/12/03 10:10:09 [debug] 5807#0: *158 http close request 2015/12/03 10:10:09 [debug] 5807#0: *158 http log handler 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000C829B0 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000C819A0 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000C80990 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000000000 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000BB1E70, unused: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000BB2E80, unused: 8 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000CB4AC0, unused: 991 2015/12/03 10:10:09 [debug] 5807#0: *158 close http connection: 19 2015/12/03 10:10:09 [debug] 5807#0: *158 reusable connection: 0 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000B4D2A0 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000BB13E0, unused: 8 2015/12/03 10:10:09 [debug] 5807#0: *158 free: 0000000000B4C990, unused: 72 }}} This request work: {{{ $ curl -ki 'https://local1.conectados.gob.ar/sitios/conectados/inicio/' HTTP/1.1 200 OK Server: nginx/1.8.0 Date: Thu, 03 Dec 2015 13:14:32 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.5.9-1ubuntu4.14 X-Varnish: 32802 53 Age: 19 Via: 1.1 varnish-v4 Accept-Ranges: bytes X-Frame-Options: DENY CONECTADOS Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 3 13:38:42 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 03 Dec 2015 13:38:42 -0000 Subject: [Varnish] #1827: Fetch no body from backend when using HTTP/1.0 and Beresp is uncacheable In-Reply-To: <046.cc50d6b17b84c5cff08ffeb40a77e2b5@varnish-cache.org> References: <046.cc50d6b17b84c5cff08ffeb40a77e2b5@varnish-cache.org> Message-ID: <061.61acbe35c8e80d215776860cbd75545f@varnish-cache.org> #1827: Fetch no body from backend when using HTTP/1.0 and Beresp is uncacheable ----------------------+-------------------- Reporter: jparedes | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by jparedes): Component shuld be varnishd, sorry. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 3 13:42:39 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 03 Dec 2015 13:42:39 -0000 Subject: [Varnish] #1827: Fetch no body from backend when using HTTP/1.0 and Beresp is uncacheable In-Reply-To: <046.cc50d6b17b84c5cff08ffeb40a77e2b5@varnish-cache.org> References: <046.cc50d6b17b84c5cff08ffeb40a77e2b5@varnish-cache.org> Message-ID: <061.7948a0556f397d13718d437aba80688e@varnish-cache.org> #1827: Fetch no body from backend when using HTTP/1.0 and Beresp is uncacheable ----------------------+--------------------- Reporter: jparedes | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+--------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I'm pretty sure this is the issue we fixed with 165f191d68c2637629b6dd4303293c328745acae (See also: #1810) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 3 17:23:05 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 03 Dec 2015 17:23:05 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.63f0eb9148ebdd2d8304835f7bc348cb@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+----------------------- Reporter: xrowkristina | Owner: Type: defect | Status: reopened Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: Keywords: | --------------------------+----------------------- Changes (by xrowkristina): * status: closed => reopened * resolution: invalid => Comment: Ok, is this maybe a bug in our VCL? Because if I sent a request via curl I didn't get Content-Length: {{{ /var/www/www.wuv.de # curl 'http://localhost/sso/linksubscription?access_token=ZDQxY2E2N2IxZGM1MTlmZDRjOGVjYTA2NmJiMGVjNjE2MGUxNDFlNjhiODM1MDY3YmQxZmU1YmNkMzUyYmYzNg&abonummer=43433443534535345' -H 'Host: kundenkonto-test.wuv.de' -H 'Accept-Language: de-DE,de;q=0.8,en- US;q=0.6,en;q=0.4' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Cookie: BIGipServerlb- varnish.wuvtest.de_6081=1678581420.49431.0000; eZSESSID=qrp3li6mn4rcq9kj4778sd2cn6; wuv-p=1678581420.49431.0000' -I }}} {{{ HTTP/1.1 204 No Content Date: Thu, 03 Dec 2015 17:19:12 GMT Server: Apache/2.4.7 (Ubuntu) X-Powered-By: PHP/5.5.9-1ubuntu4.9 Cache-Control: max-age=0, must-revalidate, public, s-maxage=0 X-Cache-Debug: 1 Vary: X-Debug-Token: fd8676 X-Debug-Token-Link: /_profiler/fd8676 Content-Type: text/html; charset=utf-8 }}} Thanks a lot Kristina -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 3 23:53:08 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 03 Dec 2015 23:53:08 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.00cd123980640b2130d7fbc6c4bd0d8b@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+---------------------- Reporter: xrowkristina | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Changes (by fgsch): * status: reopened => closed * resolution: => invalid Comment: It might be, however this is not a bug to be handled in the bug tracker. Please use the different support options available at https://www.varnish- cache.org/support. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 08:30:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 08:30:29 -0000 Subject: [Varnish] #1828: Debian: Multi-User support for init scripts Message-ID: <043.32e6198ebd74aa7ac3237883529ea078@varnish-cache.org> #1828: Debian: Multi-User support for init scripts ---------------------+------------------------- Reporter: idl0r | Type: enhancement Status: new | Priority: normal Milestone: | Component: packaging Version: unknown | Severity: normal Keywords: | ---------------------+------------------------- Hi, please see https://github.com/varnish/varnish-cache-debian/pull/1 - some Patches for multi-user support for varnish, varnishncsa and varnishlog. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 10:09:44 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 10:09:44 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.56cb95e376c2854dba3b8175521d7a1b@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+---------------------- Reporter: xrowkristina | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Comment (by Tom Anheyer): We have the same issue with piwik/piwik.php responses. Dirty workaround after migration from 3.0.7 to 4.1 for us is: {{{ sub vcl_recv { ? elsif ( req.http.host == "piwik.?" && req.url ~ "^/piwik\.php" ) { ? return (pipe); } ? }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 10:14:24 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 10:14:24 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.af926a04c7384ae00e5d217fa40b85eb@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+---------------------- Reporter: xrowkristina | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Comment (by xrowkristina): Thanks a lot Tom Anheyer. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 10:35:39 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 10:35:39 -0000 Subject: [Varnish] #1816: Return 304 for If-None-Match on weak ETag match (cache hit) In-Reply-To: <048.42c9cb84005dbc900bc1c04d266402c4@varnish-cache.org> References: <048.42c9cb84005dbc900bc1c04d266402c4@varnish-cache.org> Message-ID: <063.db68a74d12270b8720b823f0b00ec0e1@varnish-cache.org> #1816: Return 304 for If-None-Match on weak ETag match (cache hit) ---------------------------------------------+----------------------- Reporter: teohhanhui | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: 304 if-none-match weak etag hit | ---------------------------------------------+----------------------- Changes (by fgsch): * owner: => fgsch * status: new => assigned -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 12:13:24 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 12:13:24 -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.6ebbca429a2e7b86692b7c3e25a221ce@varnish-cache.org> #1763: tolerate EINTR in accept() ? ----------------------+----------------------------------------------- Reporter: slink | Owner: Martin Blix Grydeland Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------- Changes (by Martin Blix Grydeland ): * owner: => Martin Blix Grydeland * status: new => closed * resolution: => fixed Comment: In [765b6d3b3bb6f96e2c5945abe998ba9016327116]: {{{ #!CommitTicketReference repository="" revision="765b6d3b3bb6f96e2c5945abe998ba9016327116" Restart epoll_wait on EINTR error This works around a Linux kernel bug where the epoll_wait will return EINTR when the process is subjected to a ptrace or the OS wakes from suspend. Fixes: #1763 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 14:08:43 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 14:08:43 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.786cd6ef6e611d4317b7cc6edd1c05d4@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+---------------------- Reporter: xrowkristina | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Comment (by xrow): Dear fgsch, Thanks for your time. We will double check again. The Content-Length header is not delivered in the apache response (Response) that Kristina provided. But I do see it in the varnish debug output. You are most likely correct. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 15:06:45 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 15:06:45 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.46ff62ce4aaed208b7d74f5c8dd7f414@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+---------------------- Reporter: xrowkristina | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Comment (by Tom Anheyer): Thank you very mutch for your patience. Our piwik is running on apache-2.4.10/php-fpm. The apache is adding the Content-Length to EVERY request and it's impossible to fix this by {{{ Header always unset Content-Length "expr=%{REQUEST_STATUS} == 204" }}} Ignoring the not rfc compliant headers would be very nice. In my opinion varnish shouldt not be "katholischer als der Pabst" (more catholic as the pope). best regards tom -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 15:16:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 15:16:36 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.b52013f1d55d0524e4189e8a2338da06@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+---------------------- Reporter: xrowkristina | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Comment (by xrow): Hi, this sounds like an php-fpm bug or apache bug. We had the same issue as you, but it was an symfony php bug. I don?t mind varnish being strict. Now we have this sencond issue, but we don?t know yet where it belongs to. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 15:23:52 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 15:23:52 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.9bfb71f4f40c2e24f9c5d508689bb701@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+---------------------- Reporter: xrowkristina | Owner: Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: invalid Keywords: | --------------------------+---------------------- Comment (by Tom Anheyer): Hi, It's a apache issue, but no client cares about the "Content-Length: 0" header but varnish 4.1 does. tom -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 15:31:38 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 15:31:38 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.77758323a7df2d4c0e8d05a78109587c@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+----------------------- Reporter: xrowkristina | Owner: Type: defect | Status: reopened Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: Keywords: | --------------------------+----------------------- Changes (by fgsch): * status: closed => reopened * resolution: invalid => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 15:32:29 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 15:32:29 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.52054bd65f18f13f2d7145a757493bb2@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+----------------------- Reporter: xrowkristina | Owner: Type: defect | Status: reopened Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: Keywords: | --------------------------+----------------------- Comment (by fgsch): Ok. We've discussed this and we will ignore a zero C-L in the next release. Reopening the ticket until the workaround is committed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 4 23:04:20 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 04 Dec 2015 23:04:20 -0000 Subject: [Varnish] #1826: 503 backend error after response with 204 without a body, varnish 4.1 In-Reply-To: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> References: <050.bda7851e1bd9715cf6daae3c263c3e7a@varnish-cache.org> Message-ID: <065.50f7928aa8a4f4599b612f38a8c6f91e@varnish-cache.org> #1826: 503 backend error after response with 204 without a body, varnish 4.1 --------------------------+--------------------------------------------- Reporter: xrowkristina | Owner: Federico G. Schwindt Type: defect | Status: closed Priority: high | Milestone: Component: build | Version: 4.1.0 Severity: normal | Resolution: fixed Keywords: | --------------------------+--------------------------------------------- Changes (by Federico G. Schwindt ): * status: reopened => closed * owner: => Federico G. Schwindt * resolution: => fixed Comment: In [271e1c5299c5b32ee636e4a7e009fbbb5080569f]: {{{ #!CommitTicketReference repository="" revision="271e1c5299c5b32ee636e4a7e009fbbb5080569f" Ignore 0 Content-Lengths in 204 responses Broken implementations do it contrary to what the RFC mandates. Fixes #1826. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Dec 6 20:41:59 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 06 Dec 2015 20:41:59 -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.43b136c89329d143ac156e99f4a2ba86@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 nan0r): As promised and discussed on IRC, this is a plan to reproduce the issue with a minimum amount of steps, from a clean environnement (in this example a fresh docker container, running ubuntu:latest image). Please note we don't need to "reload" varnish to see the "ref count" issue. At the end of these, netstat -na is empty, and varnishadm still shows a number of references attached to the boot config. sysctl -w net.ipv4.tcp_keepalive_time=15 is there only to clean the dying tcp connetions quicker for the end of the test. ********************************************* * reproduce from scratch, minimal ******************************************** ## just to earn some time, reduce tcp keep alive to 15 on the host # sysctl -w net.ipv4.tcp_keepalive_time=15 # fresh minimal ubuntu 14.04 install (docker run -it ubuntu), image ubuntu:latest # docker run -it ubuntu # (from now, we are running command from the fresh ubuntu environnement) # install varnish and apache bench (ab) apt-get -y install apt-transport-https curl apache2-utils curl https://repo.varnish-cache.org/GPG-key.txt | apt-key add - echo "deb https://repo.varnish-cache.org/ubuntu/ trusty varnish-4.1" >> /etc/apt/sources.list.d/varnish-cache.list apt-get update apt-get -y install varnish # check version varnish varnishd -V | grep rev # varnishd (varnish-4.1.0 revision 3041728) ### setup mini config with backend not reachable echo "vcl 4.0;" > /etc/varnish/default.vcl echo "backend nonaccessible_backend { ">> /etc/varnish/default.vcl echo ".host = \"172.17.0.222\" ;" >> /etc/varnish/default.vcl echo ".port = \"80\";" >> /etc/varnish/default.vcl echo "}" >> /etc/varnish/default.vcl # start varnish /etc/init.d/varnish start sleep 3 # show number ref count before varnishadm vcl.list ab -n 100000 -c 1000 http://127.0.0.1:6081/ & sleep 5 kill $! varnishadm vcl.list # wait keepalive trigger and clean dead tcp connection # count nomber of tcp tuples in netstat netstat -nat | grep tcp # wait the netstat to be cleared sleep 20 # from now netstat should be empty from closing conenctions netstat -nat | grep -c CLOSE_WAIT # = 0, nothing left netstat -nat | wc -l # =6 # refcount still high varnishadm vcl.list # active auto/warm 957 boot ******************************************** -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sun Dec 6 22:26:55 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sun, 06 Dec 2015 22:26:55 -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.6245627eb10b4ff5e2e635651c8b67de@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 nan0r): We believe this exists in varnish 4.0.X and varnish 4.1.X. from IRC: 16:59 we think it is related to the way objects are removed from the waiting list 17:00 somehow the reference to the object is lost, and the objects never gets removed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 7 02:07:50 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Dec 2015 02:07:50 -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.f6e7e990cfc8daf794d2c2bf1ee0202b@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 lochii): I've been staring at the code for a while and I have a theory about what is happening. in the test case, we send 1000 requests to the acceptor, and, though the backend is unreachable, we end up with a busy object and thus a waitlist. Debugging, I count over 1000 requests being added to the waitinglist, but only 300 being removed before activity ceases (and the acceptor TCP sockets time out), leaving a high refcount on the objhead. The 300 actually comes from 100 x 3 , as 3 is the default rush exponent (so for each hsh_rush(), 3 times as many list items are removed as the function is called), case in point, if we increase the rush exponent parameter on the command line, more waitlist items are removed for each hsh_rush() called and the situation improves. now, why is hsh_rush() only called 100 times? debugging suggests: - 25 of these attempts come from the backend fetch error code path, vbf_stp_error() -> HSH_Unbusy() -> hsh_rush() - 25 of these come from cnt_deliver() -> HSH_DerefObjCore() -> hsh_rush() - 25 of these come from exp_expire() -> HSH_DerefObjCore() -> hsh_rush() - 25 of these come from VBO_DerefBusyObj() - HSH_DerefObjCore() -> hsh_rush() it seems to be that these come from in-flight requests, before the waitlisting started, after the waitlisting starts, all other requests seem to go onto the list to wait for the above to come and remove them (but this doesn't happen, as we never reach the required number of hsh_rush() calls) I did hope for some epoll magic to come and save the day with the expiring acceptor sockets, but alas, the sockfds are only checked by a straighforward poll() , from VTCP_check_hup() , and this only happens after the request is back off the waitlist! (in the HTTP1 FSM) so, I noticed that hsh_rush() has a ditching mechanism, if it tries to reschedule the req using SES_Reschedule_Req() and there are no available workers to do this on to, the entire waitlist (and req, and session) are all ditched. It seems that if we open up this ditching mechanism to the HSH_Unbusy() that is called from vbf_stp_error() , then when the backend is (or becomes) dysfunctional, we can stop queuing requests (as we may not be able to service them any time soon). Though I'm not sure if this is a good thing or not, I wrote a simple patch to demonstrate this (see attached) which does appear to work and, in the test case above, resolves the stuck waitlist (and refcnts) issue. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 7 12:11:04 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Dec 2015 12:11:04 -0000 Subject: [Varnish] #1828: Debian: Multi-User support for init scripts In-Reply-To: <043.32e6198ebd74aa7ac3237883529ea078@varnish-cache.org> References: <043.32e6198ebd74aa7ac3237883529ea078@varnish-cache.org> Message-ID: <058.0eed46bc43a151ce4626355bea09c5d6@varnish-cache.org> #1828: Debian: Multi-User support for init scripts -------------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: enhancement | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -------------------------+----------------------- Changes (by lkarsten): * owner: => lkarsten -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 7 12:12:03 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Dec 2015 12:12:03 -0000 Subject: [Varnish] #1828: Debian: Multi-User support for init scripts In-Reply-To: <043.32e6198ebd74aa7ac3237883529ea078@varnish-cache.org> References: <043.32e6198ebd74aa7ac3237883529ea078@varnish-cache.org> Message-ID: <058.aa37d83ee6ce527d4b75a73d6209558a@varnish-cache.org> #1828: Debian: Multi-User support for init scripts -------------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: enhancement | Status: new Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: Keywords: | -------------------------+----------------------- Comment (by lkarsten): I'm lukewarm to adding multiple instance support to the init scripts. Setting up Varnish is pretty complicated already. There are some patches here that make sense to me and should be merged. I'll have another look. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 7 14:16:46 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Dec 2015 14:16:46 -0000 Subject: [Varnish] #1802: Segfault after VCL change In-Reply-To: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> References: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> Message-ID: <061.dcc5c9b3f3ef99086e31ef35e40bc158@varnish-cache.org> #1802: Segfault after VCL change ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Tom Anheyer): similiar error: {{{ Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41273 127.0.0.1 6082 Rd auth 3f15e9186270a640b5f0958c35b1910e85cc7ab04e038021d983a67e6b0dfba0 Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41273 127.0.0.1 6082 Wr 200 ----------------------------- Varnish Cache CLI 1.0 ----------------------------- Linux,3.16.7-29-desktop,x86_64,-junix,-smalloc,-smalloc,-hcritbit varnish-4.1.0 revision 3041728 Type 'help' for command list. Type 'quit' to close CLI session. Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41273 127.0.0.1 6082 Rd ping Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41273 127.0.0.1 6082 Wr 200 PONG 1449219177 1.0 Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41273 127.0.0.1 6082 Rd vcl.load Test-2015-12-04-08:52:57 /etc/varnish/vcl.conf Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41273 127.0.0.1 6082 Wr 200 VCL compiled. ? Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41281 127.0.0.1 6082 Rd vcl.use Test-2015-12-04-08:52:57 Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41281 127.0.0.1 6082 Wr 200 VCL 'Test-2015-12-04-08:52:57' now active ? Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41285 127.0.0.1 6082 Rd vcl.list Dec 04 08:52:57 varnish varnishd[13456]: CLI telnet 127.0.0.1 41285 127.0.0.1 6082 Wr 200 available auto/warm 0 boot active auto/warm 0 Test-2015-12-04-08:52:57 ? Dec 04 09:02:59 varnish varnishd[13456]: Child (13466) not responding to CLI, killing it. Dec 04 09:02:59 varnish varnishd[13456]: Child (13466) not responding to CLI, killing it. Dec 04 09:02:59 varnish varnishd[13456]: Child (13466) died signal=11 Dec 04 09:02:59 varnish varnishd[13456]: Child (13466) Panic message: Assert error in child_sigsegv_handler(), mgt/mgt_child.c line 297: Condition(Segmentation fault by instruction at 0x5590) not true. thread = (cache-main) version = varnish-4.1.0 revision 3041728 ident = Linux,3.16.7-29-desktop,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Dec 04 09:02:59 varnish varnishd[13456]: Child (13466) died signal=11 Dec 04 09:02:59 varnish varnishd[13456]: Child (13466) Panic message: Dec 04 09:02:59 varnish varnishd[13456]: Assert error in child_sigsegv_handler(), mgt/mgt_child.c line 297: Dec 04 09:02:59 varnish varnishd[13456]: Condition(Segmentation fault by instruction at 0x5590) not true. Dec 04 09:02:59 varnish varnishd[13456]: thread = (cache-main) Dec 04 09:02:59 varnish varnishd[13456]: version = varnish-4.1.0 revision 3041728 Dec 04 09:02:59 varnish varnishd[13456]: ident = Linux,3.16.7-29-desktop,x86_64,-junix,-smalloc,-smalloc,-hcritbit,epoll Dec 04 09:02:59 varnish varnishd[13456]: Child cleanup complete Dec 04 09:02:59 varnish varnishd[13456]: Child cleanup complete Dec 04 09:02:59 varnish varnishd[13456]: child (13778) Started Dec 04 09:02:59 varnish varnishd[13456]: child (13778) Started Dec 04 09:03:00 varnish varnishd[13456]: Pushing vcls failed: Dec 04 09:03:00 varnish varnishd[13456]: Could not load compiled VCL. Dec 04 09:03:00 varnish varnishd[13456]: dlopen(vcl_boot/vgc.so) = vcl_boot/vgc.so: cannot open shared object file: No such file or directory Dec 04 09:03:00 varnish varnishd[13456]: Stopping Child Dec 04 09:03:00 varnish varnishd[13456]: Pushing vcls failed: Could not load compiled VCL. dlopen(vcl_boot/vgc.so) = vcl_boot/vgc.so: cannot open shared object file: No such file or directory Dec 04 09:03:00 varnish varnishd[13456]: Stopping Child Dec 04 09:03:01 varnish varnishd[13456]: Child (13778) ended Dec 04 09:03:01 varnish varnishd[13456]: Child (13778) ended Dec 04 09:03:01 varnish varnishd[13456]: Child (13778) said Child starts Dec 04 09:03:01 varnish varnishd[13456]: Child (13778) said Child dies Dec 04 09:03:01 varnish varnishd[13456]: Child (13778) said Child starts Dec 04 09:03:01 varnish varnishd[13456]: Child (13778) said Child dies Dec 04 09:03:01 varnish varnishd[13456]: Child cleanup complete Dec 04 09:03:01 varnish varnishd[13456]: Child cleanup complete ? }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 7 15:14:52 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Dec 2015 15:14: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.d8132b17440c1315224d2dbc1280edc3@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 lochii): {{{ [12:37] right [12:37] phk: to me the cause of #1823 isn't mapped yet. I do not believe it is the SES_Reschedule_Req() that fails and stops the propagation [12:37] -beb:#varnish-hacking- #1823: vcl in discarded mode does not clear up [new] https://www.varnish-cache.org/trac/ticket/1823 [12:40] and the single DerefObjcore on any objcore of an objhead should be sufficient to cause the entire list to be rescheduled [12:40] martin, not if we have a "leak" somewhere that stops the chain. [12:41] phk: exactly, so i still believe there must be a leak somewhere that we haven't spotted [12:41] the patch as it is would prob just mask it [12:41] martin, agree. But now we know that to be the case. [12:42] yes, so that is definitive progress [12:42] agreed too, I don't think that's the proper solution. It may still be a good idea to speed up draining the waiting list though, but it's not a proper fix for the bug. [12:43] my huch of friday that I was following was the single OC ref held by the busyobj, and somehow the initiating client worker and the fetch worker ref of the busyobj got screwed up [12:44] causing that ref to sit idle [12:44] martin, Well, that would be quick to test if we have a VTC. [12:45] yeah [12:45] I think we should focus on writing the VTC... [12:45] martin: re: 'single DerefObjcore' , how should that work? [12:45] ultimately, it just calls a normal hsh_rush() [12:45] it isn't doing anything special [12:45] which in turn would wake up some thread somewhere [12:45] yes, it does [12:45] which calls another hsh_rush() [12:45] which would have a ref of some objcore on the same objhead [12:46] but not enough times [12:46] if the wl is big enough [12:46] lochii, the point is that "big enough" shouldn't matter. [12:46] which would in turn cause hsh_rush to be called on the WL of the objhead when it's dereferenced [12:46] Notification successfully posted. [12:46] so the chain is propagated [12:47] right, but the hsh_rush only removes $rush_exponent items [12:47] from the wl [12:47] in this case, 3 [12:47] true, but for each of those $rush_exponent more should be woken [12:48] lochii, but each of those should also remove 3 [12:48] Notification successfully posted. [12:48] lochii, it's supposed to be a cascade, and somewhere it isn't [12:48] Notification successfully posted. [12:48] hsh_rush() does wrk->stats->busy_wakeup++; [12:48] but that's about it [12:50] how does (or should) this wakeup work? [12:50] lochii: it calls SES_Reschedule_Req() [12:50] Notification successfully posted. [12:50] yes [12:50] that causes a req to be processed that is already waiting on this objhead [12:51] ok, so that puts a SES_Proto_Req on the task list [12:51] so it must get an objcore ref on the same objhead [12:51] which when deref'ed would call hsh_rush again 12:51] so if those statements are all true, the list would not stall [12:52] I only ever see 25 SES_Reschedule_Req()s being called [12:52] for 1000 requests [12:52] yeah, and that is wrong [12:52] sorry, 300 [12:52] are there any failures to get worker threads ? [12:53] that might break the chain [12:53] the stats are negative on that [12:53] well, if the reschedule fails, it is supposed to ditch the wl [12:54] since you cascade the return of pool_task [12:57] when it calls SES_Proto_Req -> HTTP1_Session , it ends up in S_STP_H1BUSY [12:58] and this does in turn HSH_DerefObjHead() and Req_Cleanup() [12:58] ah [12:58] there you have it [12:58] hsh_derefobjhead wouldn't call hsh_ursh [12:59] yes [12:59] it doesn't [12:59] I dont know why [12:59] but I've just been guessing by staring at this code for so long, as to how it is supposed to work [13:00] right - so that's the broken link [13:00] ok [13:00] the VTCP_check_hup notices the client has gone away while on the waitinglist [13:00] yes, I saw that [13:00] which causes a quick escape of the handling [13:00] which causes a quick escape of the handling [13:00] wondering why when epoll waiter is enabled that we don't add epoll monitoring for these sockets [13:03] ok, testing now with hsh_rush() in the HSH_DerefObjHead() path [13:06] lochii, the waiting list predates the general waiter [13:06] Notification successfully posted. [13:06] lochii, it's also not obvious that it would be cheaper. [13:06] Notification successfully posted. [13:07] [clara] [nan0r(~ronank at 195.8.70.15)] not coming to the team meeting ? [13:07] Notification successfully posted. [13:09] [clara] [msg(nan0r)] incident with l3, be there shortly [13:10] ok, seems to be working , albeit slowly [13:11] will keep an eye on it [13:11] lochii, slowly in what way ? [13:11] Notification successfully posted. [13:11] as in, the refcnt is draining [13:11] as the cascade is happening [13:11] and threads are being woken up [13:11] just happening really slowly [13:12] lochii so the cascade is not widening ? [13:12] Notification successfully posted. [13:12] no [13:12] ok, its stuck again [13:13] ah [13:13] objcore refcnt is now zero [13:13] so we are no longer deref objcore [13:14] which means we stopped deref objhead [13:14] but I"ve still got the oh with refcnt of 800+ [13:14] so its stalled here now [13:16] that sounds strange... [14:50] ok, looks like I've got it working [14:51] if hsh_rush() is called properly in HSH_DerefObjHead() it does indeed work [14:51] I need to test some stuff with the private oh [14:52] but generally it works [14:52] so let me re-make the patch [14:52] (though it would be nice to see ditch functionality, I'll keep it out of this if it isn't needed) another patch follows. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 7 15:48:08 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Dec 2015 15:48:08 -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.15e2c0d967f31f2195c746abd3e46f69@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 lochii): ok, two patches attached, 1823.2.patch is less invasive, and we call hsh_rush() directly in HSH_DerefObjHead(), but an extra lock can be involved with a non-private oh (as the hashing algorithm does its own lock to do refcnt decrement), patch 1823.3.patch brings the hsh_rush() into the hash algorithm , but is more invasive as a result (but you save an additional locking step). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 7 17:34:41 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 07 Dec 2015 17:34:41 -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.7da1b5aa5d56f88a67866616938eec04@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): Do you need more information? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 8 14:00:02 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 08 Dec 2015 14:00:02 -0000 Subject: [Varnish] #1802: Segfault after VCL change In-Reply-To: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> References: <046.db002b3f9fce758373ff6d1d348871ef@varnish-cache.org> Message-ID: <061.bd490622d8da9ae2488ba91fdd86221c@varnish-cache.org> #1802: Segfault after VCL change ----------------------+-------------------- Reporter: lkarsten | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by Tom Anheyer): Please ignore last comment. We have used a command line like: {{{ varnishd -C -f "/etc/varnish/vcl.conf" }}} to precheck a new vcl before loading. This deletes the shared object of the current running 'boot' config. best regards tom -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 9 08:10:12 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 09 Dec 2015 08:10:12 -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.5bbe3525b68c1322b2a2d57ba27b5a97@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): Hi, We are now 10 days later and the first varnishd crash has occurred :( 1. I have attached a full core dump and a part of the syslog (there was nothing else in syslog that was relevant). Archive: https://dl.dropboxusercontent.com/u/5629939/temp/20151209%200704h%20varnishd%20crash.7z 2. The varnishd cmdline params can be found in the syslog. 3. This is the VCL. Archive: https://dl.dropboxusercontent.com/u/5629939/temp/20151209%200704h%20varnishd%20vcl.7z I hope this will help to identify the cause of the accidental crashes. Thanks for your help. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 9 14:42:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 09 Dec 2015 14:42:36 -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.d3923fb79609fe82b0b051e5101cab6d@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: | -------------------------+----------------------------------------- Changes (by slink): * cc: nils.goroll@? (added) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 10 10:30:14 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 10 Dec 2015 10:30:14 -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.d0d35d2cbde915d6f4e3ac99d156858e@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): Internal note: All supported Linux distros with the exception of (Debian) jessie ship with a pcre version older than 8.32, thus jit is not enabled on those platforms. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 11 15:32:06 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 11 Dec 2015 15:32:06 -0000 Subject: [Varnish] #1816: Return 304 for If-None-Match on weak ETag match (cache hit) In-Reply-To: <048.42c9cb84005dbc900bc1c04d266402c4@varnish-cache.org> References: <048.42c9cb84005dbc900bc1c04d266402c4@varnish-cache.org> Message-ID: <063.b064b67e853cfb8dd390ab29e4f49f04@varnish-cache.org> #1816: Return 304 for If-None-Match on weak ETag match (cache hit) ---------------------------------------------+--------------------- Reporter: teohhanhui | Owner: fgsch Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: 304 if-none-match weak etag hit | ---------------------------------------------+--------------------- Changes (by Federico G. Schwindt ): * status: assigned => closed * resolution: => fixed Comment: In [6469345568aa852258e71df7e42492dfe8cac46b]: {{{ #!CommitTicketReference repository="" revision="6469345568aa852258e71df7e42492dfe8cac46b" Use a weak comparison function for If-None-Match As per RFC 7232. Fixes #1816. }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 12 10:37:20 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 12 Dec 2015 10:37:20 -0000 Subject: [Varnish] #1797: Content-Type/Content-Length should miss on 304 requests In-Reply-To: <048.25fbf3261b6557b2bc77d60ef0f32406@varnish-cache.org> References: <048.25fbf3261b6557b2bc77d60ef0f32406@varnish-cache.org> Message-ID: <063.18a529d5ca6fbf1d01232988963123eb@varnish-cache.org> #1797: Content-Type/Content-Length should miss on 304 requests ------------------------+-------------------- Reporter: shakalandy | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Comment (by fgsch): Some details from RFC7232 4.1 p19: {{{ The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field). }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 12 10:37:32 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 12 Dec 2015 10:37:32 -0000 Subject: [Varnish] #1797: Content-Type/Content-Length should miss on 304 requests In-Reply-To: <048.25fbf3261b6557b2bc77d60ef0f32406@varnish-cache.org> References: <048.25fbf3261b6557b2bc77d60ef0f32406@varnish-cache.org> Message-ID: <063.e42de3e12271219c9373ede5af8f78fb@varnish-cache.org> #1797: Content-Type/Content-Length should miss on 304 requests ------------------------+----------------------- Reporter: shakalandy | Owner: fgsch Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: Keywords: | ------------------------+----------------------- Changes (by fgsch): * status: new => assigned * owner: => fgsch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 14 10:49:43 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Dec 2015 10:49:43 -0000 Subject: [Varnish] #1829: dev package dependency Message-ID: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> #1829: dev package dependency --------------------+--------------------- Reporter: fgsch | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Keywords: --------------------+--------------------- The dev package ships varnishapi.pc but doesn't depend on pkg-config. We should consider changing this unless distro packaging policies state otherwise. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 14 12:04:37 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Dec 2015 12:04:37 -0000 Subject: [Varnish] #1829: dev package dependency In-Reply-To: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> References: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> Message-ID: <058.5e69688131267df97b1dc0149a7e6eb2@varnish-cache.org> #1829: dev package dependency --------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+----------------------- Changes (by lkarsten): * owner: => lkarsten Comment: Mentioned in: https://github.com/varnishcache/pkg-varnish- cache/blob/master/debian/control Missing here: https://github.com/varnishcache/pkg-varnish- cache/blob/master/redhat/varnish.spec (unless it is implicit on el?) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 14 12:39:23 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Dec 2015 12:39:23 -0000 Subject: [Varnish] #1829: dev package dependency In-Reply-To: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> References: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> Message-ID: <058.8562de851a4a992145fb5aa8e4675be5@varnish-cache.org> #1829: dev package dependency --------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+----------------------- Comment (by fgsch): Re debian, that's in the build-depends, not depends. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 14 14:58:28 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Dec 2015 14:58:28 -0000 Subject: [Varnish] #1830: VSL API: "duplicate link" errors in request grouping when vsl_buffer is increased Message-ID: <043.aa684f175db5954239cc4d4515a36183@varnish-cache.org> #1830: VSL API: "duplicate link" errors in request grouping when vsl_buffer is increased -------------------------------------------+---------------------- Reporter: geoff | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.3 | Severity: normal Keywords: VSL,duplicate link,vsl_buffer | -------------------------------------------+---------------------- We have an app that uses the VSL API to extract data from the log, always in request grouping. Last week we increased vsl_buffer (to reduce SHM lock contention), and are now encountering very many "duplicate link" errors in the synthetic VSL record. It turns out that the errors no longer occur when we set vsl_buffer back to the lower value, and appear again when it is increased (we can "turn it on and off" by changing vsl_buffer with param.set). Previously we had vsl_buffer==default==4k, and increased it to 32k. By tweaking with param.set, I find that the errors are essentially gone with vsl_buffer up to about 5400 to 5500, although this was at low load on the site. The VSL errors seem to gradually occur more frequently as we increase vsl_buffer. I could get the same effect by running: {{{ # with the same -L and -T parameters used by the app $ varnishlog -g request -q VSL }}} The query starts getting hits when vsl_buffer is above the same threshold, and more hits as vsl_buffer is increased. The site uses extensive nesting of ESI includes, up to at least esi_level==6, so request grouping assembles a large tree. As far as we can tell, we're not losing any of the data that the app is meant to collect; I wouldn't say this is certain, but so far VSL appears to me to be presenting all of the data that it should be. Put another way: so far I can't see anything else that is wrong due to the "duplicate links". So the problem is not a show-stopper (although we have the problem that we log all VSL records as errors, so our logs are currently being flooded). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 14 15:20:57 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Dec 2015 15:20:57 -0000 Subject: [Varnish] #1830: VSL API: "duplicate link" errors in request grouping when vsl_buffer is increased In-Reply-To: <043.aa684f175db5954239cc4d4515a36183@varnish-cache.org> References: <043.aa684f175db5954239cc4d4515a36183@varnish-cache.org> Message-ID: <058.9dc44589a5def72bacb7872cadbdd0be@varnish-cache.org> #1830: VSL API: "duplicate link" errors in request grouping when vsl_buffer is increased -------------------------------------------+------------------------------- Reporter: geoff | Owner: Type: defect | Status: new Priority: normal | Milestone: Varnish 4.0 Component: varnishd | release Severity: normal | Version: 4.0.3 Keywords: VSL,duplicate link,vsl_buffer | Resolution: -------------------------------------------+------------------------------- Changes (by slink): * cc: nils.goroll@? (added) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 14 18:03:37 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 14 Dec 2015 18:03:37 -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.c4d1618d2226b58ecc270a3a770c6eed@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 agaltier): Hi,[[BR]] You can add in your /etc/systemd/system/varnishncsa.service[[BR]] {{{ [Service] [...] Restart=on-failure RestartSec=5s [...] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 08:20:55 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 08:20:55 -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.f993f7fc353a6783e574b36a618497e8@varnish-cache.org> #1824: Varnish.service should be using type=notify ----------------------+--------------------- Reporter: zmyrgel | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 4.0.3 Severity: normal | Resolution: fixed Keywords: systemd | ----------------------+--------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: Hi. Yes, that would be a brute-force workaround for this issue. Adding "-t off" is, as explained, another option. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 08:36:05 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 08:36:05 -0000 Subject: [Varnish] #1831: random Panic's at recent master Message-ID: <048.1beaeb0068a5cc74ba11a7ada820f9b0@varnish-cache.org> #1831: random Panic's at recent master ------------------------+---------------------- Reporter: hjanuschka | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: trunk | Severity: normal Keywords: | ------------------------+---------------------- Child (38439) Panic at: Tue, 15 Dec 2015 08:07:03 GMT#012"Assert error in VDP_bytes(), cache/cache_deliver_proc.c line 49:#012 Condition(act > VDP_NULL || len > 0) not true.#012thread = (cache-worker)#012version = varnish-trunk revision 2c76f5b#012ident = Linux,3.16.0-4-amd64,x86_64,-jnone,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 0x431d12: pan_ic+0x152#012 0x41a598: VDP_bytes+0xb8#012 0x4624c2: sml_iterator+0x252#012 0x44b498: V1D_Deliver+0x228#012 0x4343bf: cnt_vdp+0x11f#012 0x435aa6: CNT_Request+0x1496#012 0x44c0d3: HTTP1_Session+0xd3#012 0x437f01: SES_Proto_Req+0x61#012 0x446b6a: WRK_Thread+0x45a#012 0x446fbb: pool_thread+0x2b#012req = 0x7fb3e81a6460 {#012 vxid = 10649615, step = R_STP_DELIVER,#012 req_body = R_BODY_NONE,#012 restarts = 0, esi_level = 0,#012 sp = 0x7fb3e81a6250 {#012 fd = 468, vxid = 10649614,#012 client = 92.123.224.148 55483,#012 step = S_STP_H1PROC,#012 },#012 worker = 0x7fb3dd978cc0 {#012 stack = {0x7fb3dd979000 -> 0x7fb3dd96d000},#012 ws = 0x7fb3dd978eb8 {#012 id = \"wrk\",#012 {s,f,r,e} = {0x7fb3dd978460,0x7fb3dd978460,(nil),+2040},#012 },#012 VCL::method = DELIVER,#012 VCL::return = deliver,#012 VCL::methods = {RECV, HASH, HIT, DELIVER},#012 },#012 ws = 0x7fb3e81a6640 {#012 id = \"req\",#012 {s,f,r,e} = {0x7fb3e81a8440,+2536,+57336,+57336},#012 },#012 http_conn = 0x7fb3e81a6568 {#012 fd = 468,#012 doclose = NULL,#012 ws = 0x7fb3e81a6640,#012 {rxbuf_b, rxbuf_e} = {0x7fb3e81a8440, 0x7fb3e81a8990},#012 {pipeline_b, pipeline_e} = {(nil), (nil)},#012 content_length = -1,#012 body_status = none,#012 first_byte_timeout = 0.000000,#012 between_bytes_timeout = 0.000000,#012 },#012 http[req] = 0x7fb3e81a66d8 {#012 ws[req] = 0x7fb3e81a6640,#012 hdrs {#012 \"GET\",#012 \"/static/sid/438/kmprog/index.xml\",#012 \"HTTP/1.1\",#012 \"If-Modified-Since: Tue, 15 Dec 2015 07:55:36 GMT\",#012 \"Accept: */*\",#012 \"Pragma: no-cache\",#012 \"Expires: 0\",#012 \"Last-Modified: Thu Jan 01 1970 01:00:00 GMT+0100 (Mitteleurop\303\244ische Zeit)\",#012 \"Referer: http://www.krone.at/\",#012 \"Accept-Language: de-DE\",#012 \"User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko\",#012 \"True-Client-IP: 93.220.47.198\",#012 \"X -Akamai-CONFIG-LOG-DETAIL: true\",#012 \"TE: chunked;q=1.0\",#012 \"Connection: TE, keep-alive\",#012 \"Akamai-Origin-Hop: 2\",#012 \"Via: 1.1 v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 akamai.net(ghost) (AkamaiGHost)\",#012 \"Host: www.krone.at\",#012 \"Accept- Encoding: gzip\",#012 \"X-Forwarded-For: 93.220.47.198, 84.53.136.40, 92.123.224.148, 92.123.224.148\",#012 \"X-passthrough-headers: yes\",#012 \"X-Varnish-TTL: 899.954\",#012 \"X-Varnish-Cache: HIT\",#012 },#012 },#012 http[resp] = 0x7fb3e81a6fc8 {#012 ws[req] = 0x7fb3e81a6640,#012 hdrs {#012 \"HTTP/1.1\",#012 \"200\",#012 \"OK\",#012 \"Date: Tue, 15 Dec 2015 08:07:02 GMT\",#012 \"Last-Modified: Tue, 15 Dec 2015 08:06:13 GMT\",#012 \"Cache-Control: max-age=480\",#012 \"Expires: Tue, 15 Dec 2015 08:15:02 GMT\",#012 \"Content-Type: text/xml\",#012 \"x-url: /static/sid/438/kmprog/index.xml\",#012 \"x-host: www.krone.at\",#012 \"X-Varnish-BE: hps_director\",#012 \"Content-Encoding: gzip\",#012 \"Vary: Accept-Encoding\",#012 \"Age: 0\",#012 \"X-Varnish-Node: asgard\",#012 \"X-Varnish-TTL: 899.954\",#012 \"X-Varnish-Cache: HIT\",#012 \"Connection: close\",#012 \"Server: Varnish\",#012 \"X-Powered-By: Curiosity\",#012 \"Accept-Ranges: bytes\",#012 \"Content-Length: 124\",#012 },#012 },#012 vcl = {#012 temp = warm#012 srcname = {#012 \"input\",#012 \"Builtin\",#012 \"/opt/varnish/confs/backends.vcl\",#012 \"/opt/varnish/confs/security/vfw.vcl\",#012 \"/opt/varnish/confs/security/protocol.vcl\",#012 \"/opt/varnish/confs/security/paths.vcl\",#012 \"/opt/varnish/confs/security/generic.vcl\",#012 \"/opt/varnish/confs/security/sql.vcl\",#012 \"/opt/varnish/confs/security/xss.vcl\",#012 \"/opt/varnish/confs/node.vcl\",#012 },#012 },#012 objcore[REQ] = 0x7fb3e81334f0 {#012 refcnt = 2,#012 flags = 0x0,#012 objhead = 0x7fb3e81333a0,#012 stevedore = 0xd08d90 (malloc s0),#012 },#012 flags = {#012 is_hit,#012 },#012},#012#012" recently upgraded to master and now my logs are receiving the following panic from time to time resulting in a crash -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 08:41:52 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 08:41:52 -0000 Subject: [Varnish] #1829: dev package dependency In-Reply-To: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> References: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> Message-ID: <058.452169a1875a7e7a2c4d970eb8c3bb2c@varnish-cache.org> #1829: dev package dependency --------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+----------------------- Comment (by lkarsten): Looking at the distro policies: https://www.debian.org/doc/debian-policy/ch-relationships.html {{{ Depends This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured (unless there is a circular dependency as described above). The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. }}} Working my way through `apt-cache rdepends pkg-config` looking for a notable ones, I'm not able to find any -dev package that has it as Depends. Package linux-source-3.16 lists it as Suggests. {{{ $?apt-cache show linux-source-3.16 Package: linux-source-3.16 Source: linux Version: 3.16.7-ckt11-1+deb8u3 Installed-Size: 81627 Maintainer: Debian Kernel Team Architecture: all Depends: binutils, bzip2 Recommends: libc6-dev | libc-dev, gcc, make, bc Suggests: libncurses-dev | ncurses-dev, libqt4-dev, pkg-config }}} The Redhat/Fedora guidelines are here: https://fedoraproject.org/wiki/Packaging:Guidelines We provide the suggested pkgconfig() feature/flag, for other packages requiring varnishapi. {{{ [lkarsten at el7 ~]$ rpm -q --provides varnish-libs-devel varnish-libs-devel = 4.0.3-1.el7.centos varnish-libs-devel(x86-64) = 4.0.3-1.el7.centos pkgconfig(varnishapi) = 4.0.3 varnishabi-strict-b8c4a34 varnishabi-1.2 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 13:36:45 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 13:36:45 -0000 Subject: [Varnish] #1829: dev package dependency In-Reply-To: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> References: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> Message-ID: <058.f9a116a270409cde9287a246e3f13fb3@varnish-cache.org> #1829: dev package dependency --------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+----------------------- Comment (by fgsch): On Debian: {{{ $ apt-cache rdepends pkg-config | grep -- -dev | wc -l 265 }}} Similar output for Ubuntu. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 14:05:27 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 14:05:27 -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.1a078f8473b1c598fae161236bec750c@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: | --------------------------+----------------------- Comment (by KlavsKlavsen): I just verified.. its possible to make it work with systemd like this: (example for apache).. ExecReload=/sbin/apachectl configtest && /usr/sbin/httpd $OPTIONS -k graceful it catches reload.. NOT restart though. But I can make sure my configuration management modules use reload (in case they use restart).. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 14:05:38 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 14:05:38 -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.e9e2b284104d11180baad9d0d5e8d753@varnish-cache.org> #1666: make init script check config before restarting --------------------------+----------------------- Reporter: KlavsKlavsen | Owner: lkarsten Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------------+----------------------- Changes (by KlavsKlavsen): * status: closed => reopened * resolution: fixed => -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 14:09:22 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 14:09:22 -0000 Subject: [Varnish] #1831: random Panic's at recent master In-Reply-To: <048.1beaeb0068a5cc74ba11a7ada820f9b0@varnish-cache.org> References: <048.1beaeb0068a5cc74ba11a7ada820f9b0@varnish-cache.org> Message-ID: <063.4b6940554f34420763c2d8a44eeaacd9@varnish-cache.org> #1831: random Panic's at recent master ------------------------+-------------------- Reporter: hjanuschka | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+-------------------- Description changed by fgsch: Old description: > Child (38439) Panic at: Tue, 15 Dec 2015 08:07:03 GMT#012"Assert error in > VDP_bytes(), cache/cache_deliver_proc.c line 49:#012 Condition(act > > VDP_NULL || len > 0) not true.#012thread = (cache-worker)#012version = > varnish-trunk revision 2c76f5b#012ident = > Linux,3.16.0-4-amd64,x86_64,-jnone,-smalloc,-smalloc,-hcritbit,epoll#012Backtrace:#012 > 0x431d12: pan_ic+0x152#012 0x41a598: VDP_bytes+0xb8#012 0x4624c2: > sml_iterator+0x252#012 0x44b498: V1D_Deliver+0x228#012 0x4343bf: > cnt_vdp+0x11f#012 0x435aa6: CNT_Request+0x1496#012 0x44c0d3: > HTTP1_Session+0xd3#012 0x437f01: SES_Proto_Req+0x61#012 0x446b6a: > WRK_Thread+0x45a#012 0x446fbb: pool_thread+0x2b#012req = 0x7fb3e81a6460 > {#012 vxid = 10649615, step = R_STP_DELIVER,#012 req_body = > R_BODY_NONE,#012 restarts = 0, esi_level = 0,#012 sp = 0x7fb3e81a6250 > {#012 fd = 468, vxid = 10649614,#012 client = 92.123.224.148 > 55483,#012 step = S_STP_H1PROC,#012 },#012 worker = 0x7fb3dd978cc0 > {#012 stack = {0x7fb3dd979000 -> 0x7fb3dd96d000},#012 ws = > 0x7fb3dd978eb8 {#012 id = \"wrk\",#012 {s,f,r,e} = > {0x7fb3dd978460,0x7fb3dd978460,(nil),+2040},#012 },#012 VCL::method > = DELIVER,#012 VCL::return = deliver,#012 VCL::methods = {RECV, > HASH, HIT, DELIVER},#012 },#012 ws = 0x7fb3e81a6640 {#012 id = > \"req\",#012 {s,f,r,e} = {0x7fb3e81a8440,+2536,+57336,+57336},#012 > },#012 http_conn = 0x7fb3e81a6568 {#012 fd = 468,#012 doclose = > NULL,#012 ws = 0x7fb3e81a6640,#012 {rxbuf_b, rxbuf_e} = > {0x7fb3e81a8440, 0x7fb3e81a8990},#012 {pipeline_b, pipeline_e} = > {(nil), (nil)},#012 content_length = -1,#012 body_status = > none,#012 first_byte_timeout = 0.000000,#012 between_bytes_timeout > = 0.000000,#012 },#012 http[req] = 0x7fb3e81a66d8 {#012 ws[req] = > 0x7fb3e81a6640,#012 hdrs {#012 \"GET\",#012 > \"/static/sid/438/kmprog/index.xml\",#012 \"HTTP/1.1\",#012 > \"If-Modified-Since: Tue, 15 Dec 2015 07:55:36 GMT\",#012 \"Accept: > */*\",#012 \"Pragma: no-cache\",#012 \"Expires: 0\",#012 > \"Last-Modified: Thu Jan 01 1970 01:00:00 GMT+0100 > (Mitteleurop\303\244ische Zeit)\",#012 \"Referer: > http://www.krone.at/\",#012 \"Accept-Language: de-DE\",#012 > \"User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) > like Gecko\",#012 \"True-Client-IP: 93.220.47.198\",#012 \"X > -Akamai-CONFIG-LOG-DETAIL: true\",#012 \"TE: chunked;q=1.0\",#012 > \"Connection: TE, keep-alive\",#012 \"Akamai-Origin-Hop: 2\",#012 > \"Via: 1.1 v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 akamai.net(ghost) > (AkamaiGHost)\",#012 \"Host: www.krone.at\",#012 \"Accept- > Encoding: gzip\",#012 \"X-Forwarded-For: 93.220.47.198, > 84.53.136.40, 92.123.224.148, 92.123.224.148\",#012 \"X-passthrough- > headers: yes\",#012 \"X-Varnish-TTL: 899.954\",#012 \"X > -Varnish-Cache: HIT\",#012 },#012 },#012 http[resp] = 0x7fb3e81a6fc8 > {#012 ws[req] = 0x7fb3e81a6640,#012 hdrs {#012 > \"HTTP/1.1\",#012 \"200\",#012 \"OK\",#012 \"Date: Tue, 15 > Dec 2015 08:07:02 GMT\",#012 \"Last-Modified: Tue, 15 Dec 2015 > 08:06:13 GMT\",#012 \"Cache-Control: max-age=480\",#012 > \"Expires: Tue, 15 Dec 2015 08:15:02 GMT\",#012 \"Content-Type: > text/xml\",#012 \"x-url: /static/sid/438/kmprog/index.xml\",#012 > \"x-host: www.krone.at\",#012 \"X-Varnish-BE: hps_director\",#012 > \"Content-Encoding: gzip\",#012 \"Vary: Accept-Encoding\",#012 > \"Age: 0\",#012 \"X-Varnish-Node: asgard\",#012 \"X-Varnish- > TTL: 899.954\",#012 \"X-Varnish-Cache: HIT\",#012 \"Connection: > close\",#012 \"Server: Varnish\",#012 \"X-Powered-By: > Curiosity\",#012 \"Accept-Ranges: bytes\",#012 \"Content- > Length: 124\",#012 },#012 },#012 vcl = {#012 temp = warm#012 > srcname = {#012 \"input\",#012 \"Builtin\",#012 > \"/opt/varnish/confs/backends.vcl\",#012 > \"/opt/varnish/confs/security/vfw.vcl\",#012 > \"/opt/varnish/confs/security/protocol.vcl\",#012 > \"/opt/varnish/confs/security/paths.vcl\",#012 > \"/opt/varnish/confs/security/generic.vcl\",#012 > \"/opt/varnish/confs/security/sql.vcl\",#012 > \"/opt/varnish/confs/security/xss.vcl\",#012 > \"/opt/varnish/confs/node.vcl\",#012 },#012 },#012 objcore[REQ] = > 0x7fb3e81334f0 {#012 refcnt = 2,#012 flags = 0x0,#012 objhead = > 0x7fb3e81333a0,#012 stevedore = 0xd08d90 (malloc s0),#012 },#012 > flags = {#012 is_hit,#012 },#012},#012#012" > > recently upgraded to master and now my logs are receiving the following > panic from time to time resulting in a crash New description: {{{ Child (38439) Panic at: Tue, 15 Dec 2015 08:07:03 GMT "Assert error in VDP_bytes(), cache/cache_deliver_proc.c line 49: Condition(act > VDP_NULL || len > 0) not true. thread = (cache-worker) version = varnish-trunk revision 2c76f5b ident = Linux,3.16.0-4-amd64,x86_64,-jnone,-smalloc,-smalloc,-hcritbit,epoll Backtrace: 0x431d12: pan_ic+0x152 0x41a598: VDP_bytes+0xb8 0x4624c2: sml_iterator+0x252 0x44b498: V1D_Deliver+0x228 0x4343bf: cnt_vdp+0x11f 0x435aa6: CNT_Request+0x1496 0x44c0d3: HTTP1_Session+0xd3 0x437f01: SES_Proto_Req+0x61 0x446b6a: WRK_Thread+0x45a 0x446fbb: pool_thread+0x2b req = 0x7fb3e81a6460 { vxid = 10649615, step = R_STP_DELIVER, req_body = R_BODY_NONE, restarts = 0, esi_level = 0, sp = 0x7fb3e81a6250 { fd = 468, vxid = 10649614, client = 92.123.224.148 55483, step = S_STP_H1PROC, }, worker = 0x7fb3dd978cc0 { stack = {0x7fb3dd979000 -> 0x7fb3dd96d000}, ws = 0x7fb3dd978eb8 { id = "wrk", {s,f,r,e} = {0x7fb3dd978460,0x7fb3dd978460,(nil),+2040}, }, VCL::method = DELIVER, VCL::return = deliver, VCL::methods = {RECV, HASH, HIT, DELIVER}, }, ws = 0x7fb3e81a6640 { id = "req", {s,f,r,e} = {0x7fb3e81a8440,+2536,+57336,+57336}, }, http_conn = 0x7fb3e81a6568 { fd = 468, doclose = NULL, ws = 0x7fb3e81a6640, {rxbuf_b, rxbuf_e} = {0x7fb3e81a8440, 0x7fb3e81a8990}, {pipeline_b, pipeline_e} = {(nil), (nil)}, content_length = -1, body_status = none, first_byte_timeout = 0.000000, between_bytes_timeout = 0.000000, }, http[req] = 0x7fb3e81a66d8 { ws[req] = 0x7fb3e81a6640, hdrs { "GET", "/static/sid/438/kmprog/index.xml", "HTTP/1.1", "If-Modified-Since: Tue, 15 Dec 2015 07:55:36 GMT", "Accept: */*", "Pragma: no-cache", "Expires: 0", "Last-Modified: Thu Jan 01 1970 01:00:00 GMT+0100 (Mitteleurop\303\244ische Zeit)", "Referer: http://www.krone.at/", "Accept-Language: de-DE", "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko", "True-Client-IP: 93.220.47.198", "X-Akamai-CONFIG-LOG-DETAIL: true", "TE: chunked;q=1.0", "Connection: TE, keep-alive", "Akamai-Origin-Hop: 2", "Via: 1.1 v1-akamaitech.net(ghost) (AkamaiGHost), 1.1 akamai.net(ghost) (AkamaiGHost)", "Host: www.krone.at", "Accept-Encoding: gzip", "X-Forwarded-For: 93.220.47.198, 84.53.136.40, 92.123.224.148, 92.123.224.148", "X-passthrough-headers: yes", "X-Varnish-TTL: 899.954", "X-Varnish-Cache: HIT", }, }, http[resp] = 0x7fb3e81a6fc8 { ws[req] = 0x7fb3e81a6640, hdrs { "HTTP/1.1", "200", "OK", "Date: Tue, 15 Dec 2015 08:07:02 GMT", "Last-Modified: Tue, 15 Dec 2015 08:06:13 GMT", "Cache-Control: max-age=480", "Expires: Tue, 15 Dec 2015 08:15:02 GMT", "Content-Type: text/xml", "x-url: /static/sid/438/kmprog/index.xml", "x-host: www.krone.at", "X-Varnish-BE: hps_director", "Content-Encoding: gzip", "Vary: Accept-Encoding", "Age: 0", "X-Varnish-Node: asgard", "X-Varnish-TTL: 899.954", "X-Varnish-Cache: HIT", "Connection: close", "Server: Varnish", "X-Powered-By: Curiosity", "Accept-Ranges: bytes", "Content-Length: 124", }, }, vcl = { temp = warm srcname = { "input", "Builtin", "/opt/varnish/confs/backends.vcl", "/opt/varnish/confs/security/vfw.vcl", "/opt/varnish/confs/security/protocol.vcl", "/opt/varnish/confs/security/paths.vcl", "/opt/varnish/confs/security/generic.vcl", "/opt/varnish/confs/security/sql.vcl", "/opt/varnish/confs/security/xss.vcl", "/opt/varnish/confs/node.vcl", }, }, objcore[REQ] = 0x7fb3e81334f0 { refcnt = 2, flags = 0x0, objhead = 0x7fb3e81333a0, stevedore = 0xd08d90 (malloc s0), }, flags = { is_hit, }, }, " }}} recently upgraded to master and now my logs are receiving the following panic from time to time resulting in a crash -- -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 14:40:48 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 14:40:48 -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.7c4f8722f58a1e2ec73dfca532a7f7b9@varnish-cache.org> #1666: make init script check config before restarting --------------------------+----------------------- Reporter: KlavsKlavsen | Owner: lkarsten Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------------+----------------------- Comment (by KlavsKlavsen): I opened https://github.com/systemd/systemd/issues/2175 - in hopes of getting a solution that would also cover service varnish restart :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 14:47:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 14:47:36 -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.686a2427e386fe8e498f2ec045bffbe7@varnish-cache.org> #1666: make init script check config before restarting --------------------------+----------------------- Reporter: KlavsKlavsen | Owner: lkarsten Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------------+----------------------- Comment (by KlavsKlavsen): update.. the ExecReload with && does not work - as it's not a shell command being run.. so && is invalid.. my testing was faulty - since I found that httpd actually handles faulty config itself on graceful.. (not on restart though). hoping for a good resolution for #2175 @systemd :) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 14:49:36 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 14:49:36 -0000 Subject: [Varnish] #1829: dev package dependency In-Reply-To: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> References: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> Message-ID: <058.ebf17b5eb46d487bee12d3c56ba4dbbd@varnish-cache.org> #1829: dev package dependency --------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+----------------------- Comment (by lkarsten): Replying to [comment:4 fgsch]: > On Debian: > {{{ > $ apt-cache rdepends pkg-config | grep -- -dev | wc -l > 265 > }}} > Similar output for Ubuntu. Correct. When I did this this morning, I found that the list also included entries with the package Suggest-ed. I looked up a few of them, and didn't find much evidence of Requires. Did you get different results than me? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 15 15:12:04 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 15 Dec 2015 15:12:04 -0000 Subject: [Varnish] #1829: dev package dependency In-Reply-To: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> References: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> Message-ID: <058.887db981e5baad1dbce532ded1fb1d06@varnish-cache.org> #1829: dev package dependency --------------------+----------------------- Reporter: fgsch | Owner: lkarsten Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: unknown Severity: normal | Resolution: Keywords: | --------------------+----------------------- Comment (by fgsch): From the list of 265: {{{ Depends: 171 Suggests: 35 Recommends: 58 Breaks: 1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 17 09:19:35 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Dec 2015 09:19:35 -0000 Subject: [Varnish] #1829: dev package dependency In-Reply-To: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> References: <043.06e8782568bbcc4e238c465148ab7a2e@varnish-cache.org> Message-ID: <058.27c5d4d109caa870b6c4ff702ac81785@varnish-cache.org> #1829: dev package dependency --------------------+----------------------- Reporter: fgsch | 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: Thanks for looking this up, fgsch. Commited as fb34de8 in pkg-varnish-cache. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 17 09:32:33 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Dec 2015 09:32:33 -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.0712761c7e5306e12283cbe31c90d35a@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: reopened => closed * resolution: => fixed Comment: Hi. Thanks for bringing this up with systemd. We might make a configtest tool at some point, it has been discussed in the past. Closing as there are no more actionable items here for us. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 17 10:13:49 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Dec 2015 10:13:49 -0000 Subject: [Varnish] #1832: Bad request instead of RC 413 when http_max_hdr exceeded Message-ID: <041.6df65ccbe8964851377cf672163df7a8@varnish-cache.org> #1832: Bad request instead of RC 413 when http_max_hdr exceeded ---------------------------------+---------------------- Reporter: vko | Type: defect Status: new | Priority: normal Milestone: Varnish 4.0 release | Component: varnishd Version: 4.0.3 | Severity: normal Keywords: | ---------------------------------+---------------------- Hello, in case you send more than allowed number of headers (defined as http_max_hdr) is expected RC 413 (in varnishstat there is the description for RC 413: 413 means that HTTP headers exceeded length or count limits). Instead of RC 413 we get RC 400 Bad request. It could be a bug Thanks Vko -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 17 10:18:55 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 17 Dec 2015 10:18:55 -0000 Subject: [Varnish] #1828: Debian: Multi-User support for init scripts In-Reply-To: <043.32e6198ebd74aa7ac3237883529ea078@varnish-cache.org> References: <043.32e6198ebd74aa7ac3237883529ea078@varnish-cache.org> Message-ID: <058.ba639340c801a5a209c76c25daf03d12@varnish-cache.org> #1828: Debian: Multi-User support for init scripts -------------------------+----------------------- Reporter: idl0r | Owner: lkarsten Type: enhancement | Status: closed Priority: normal | Milestone: Component: packaging | Version: unknown Severity: normal | Resolution: fixed Keywords: | -------------------------+----------------------- Changes (by lkarsten): * status: new => closed * resolution: => fixed Comment: Merged most of changes into https://github.com/varnishcache/pkg-varnish- cache now. Multiple instances belongs in contrib or the documentation. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 18 04:32:59 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 18 Dec 2015 04:32:59 -0000 Subject: [Varnish] #1825: Cannot Start Varnish After Just Restarting The Service In-Reply-To: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> References: <048.04c5c4811e95fbd4662122cd1a7cc006@varnish-cache.org> Message-ID: <063.83384311a788f1f083b528126b745183@varnish-cache.org> #1825: Cannot Start Varnish After Just Restarting The Service ------------------------+-------------------- Reporter: ghostshell | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 4.1.0 Severity: major | Resolution: Keywords: | ------------------------+-------------------- Comment (by ghostshell): Still down, downgraded to 4.0 and everything started just fine, this only happens when upgrading to 4.1 while on CentOS 6.8 x86_64. Using the default.vcl with no changes. Shows starting OK then when checking the status service shows stopped. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 18 21:55:12 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 18 Dec 2015 21:55:12 -0000 Subject: [Varnish] #1799: Backend request coalescing fail In-Reply-To: <044.a197835a5070dbdf3a5e5ef4dd8a3ca5@varnish-cache.org> References: <044.a197835a5070dbdf3a5e5ef4dd8a3ca5@varnish-cache.org> Message-ID: <059.4257fcde8afd912c65fbaf7cfdd39b52@varnish-cache.org> #1799: Backend request coalescing fail ----------------------+-------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+-------------------- Comment (by franveux): Hi, here is some VCL that converts back a pass to deliver if this happens. It works for me in production, avoiding pass requests to backend. {{{ // workarround of 1799, assuming max-age is everytime more that 5 seconds. sub vcl_hit { if (req.http.X-VCL-HITPASS1799) { // don't pass but deliver instead std.log("vcl_hit: FIX, pass convert to deliver"); return(deliver); } // we've got a hit set req.http.X-VCL-HIT = true; } sub vcl_pass { if (req.http.X-VCL-HIT && req.restarts < 2) { // we've got a hit then a pass set req.http.X-VCL-HITPASS1799 = true; return(restart); } } sub vcl_deliver { if (req.http.X-VCL-HITPASS1799) { // fake age header to avoid the client comes back too quickly. set req.http.X-max-age = regsub(resp.http.cache-control,".*max- age=([0-9]+).*","\1"); if (std.integer(req.http.X-max-age,5) <= std.integer(resp.http.age,0)) { set resp.http.age = std.integer(req.http.X-max-age, 5) - 3; } } } }}} Fran?ois V. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 21 12:03:30 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 21 Dec 2015 12:03:30 -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.2d40829712e2800da5ea648d6279ca94@varnish-cache.org> #1819: Can't access documentation of cookie --------------------+------------------------------ Reporter: colas | Owner: lkarsten Type: defect | Status: closed Priority: normal | Milestone: Varnish 4.1-TP1 Component: build | Version: 4.1.0 Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------ Changes (by lkarsten): * status: new => closed * resolution: => worksforme Comment: Hi. As far as I can tell right now, both those links you posted work as I expected them to. Please reopen if this is not the case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 23 09:22:56 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 23 Dec 2015 09:22:56 -0000 Subject: [Varnish] #1833: sphinx rendering problem for users-guide/increasing-your-hitrate.txt Message-ID: <047.ed8db0328b114af68978ab2326329442@varnish-cache.org> #1833: sphinx rendering problem for users-guide/increasing-your-hitrate.txt -----------------------+--------------------------- Reporter: mfournier | Type: defect Status: new | Priority: normal Milestone: | Component: documentation Version: 4.1.0 | Severity: normal Keywords: | -----------------------+--------------------------- https://www.varnish-cache.org/docs/4.1/users-guide/increasing-your- hitrate.html This page is supposed to have a whole section about cookies, according to TOC. The missing content shows up when following the "show source" link. Thanks ! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Wed Dec 23 10:23:18 2015 From: varnish-bugs at varnish-cache.org (Varnish) Date: Wed, 23 Dec 2015 10:23:18 -0000 Subject: [Varnish] #1833: sphinx rendering problem for users-guide/increasing-your-hitrate.txt In-Reply-To: <047.ed8db0328b114af68978ab2326329442@varnish-cache.org> References: <047.ed8db0328b114af68978ab2326329442@varnish-cache.org> Message-ID: <062.b35babd35b970abd124d8ece4d082d80@varnish-cache.org> #1833: sphinx rendering problem for users-guide/increasing-your-hitrate.txt ---------------------------+----------------------- Reporter: mfournier | Owner: Type: defect | Status: needinfo Priority: normal | Milestone: Component: documentation | Version: 4.1.0 Severity: normal | Resolution: Keywords: | ---------------------------+----------------------- Changes (by fgsch): * status: new => needinfo Comment: What is exactly missing? I can see the exact same things in the source, "Cookies from the client" and "Cookies coming from the backend". -- Ticket URL: Varnish The Varnish HTTP Accelerator