From varnish-bugs at projects.linpro.no Mon Sep 1 15:07:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Sep 2008 15:07:30 -0000 Subject: [Varnish] #304: Build fails on "undefined reference to `pthread_self'" Message-ID: <056.32202d51d9768ebe34e5fef966fb2ac6@projects.linpro.no> #304: Build fails on "undefined reference to `pthread_self'" ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: build | Version: 2.0 Severity: normal | Keywords: beta1 ------------------------+--------------------------------------------------- The tech preview release built and ran fine. However, the current beta1 now fails to build with the following error: cc -O2 -pipe -o .libs/varnishadm varnishadm.o -L../../lib/libvarnish/.libs -lvarnish -lm -L../../lib/libvarnishcompat/.libs -lvarnishcompat -Wl,-rpath,/usr/local/lib ../../lib/libvarnish/.libs/libvarnish.so.1.0: undefined reference to `pthread_self' collect2: ld returned 1 exit status *** Error code 1 I'm guessing there may be differences between pthread and pthread_np. Any other information I can provide to help diagnose this? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 1 15:44:26 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Sep 2008 15:44:26 -0000 Subject: [Varnish] #305: 2.0 beta1 cannot be built on MacOSX Message-ID: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no> #305: 2.0 beta1 cannot be built on MacOSX ---------------------+------------------------------------------------------ Reporter: 191919 | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: build | Version: trunk Severity: blocker | Keywords: ---------------------+------------------------------------------------------ $ ./configure ... $ make ... gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -DVARNISH_STATE_DIR='"/usr/local/var/varnish"' -g -O2 -MT varnishd- cache_vrt_acl.o -MD -MP -MF .deps/varnishd-cache_vrt_acl.Tpo -c -o varnishd-cache_vrt_acl.o `test -f 'cache_vrt_acl.c' || echo './'`cache_vrt_acl.c In file included from cache.h:52, from cache_vrt_acl.c:39: heritage.h:74: error: syntax error before 'uid_t' heritage.h:74: warning: no semicolon at end of struct or union heritage.h:181: error: syntax error before '}' token make[3]: *** [varnishd-cache_vrt_acl.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 A proposed patch: --- heritage.h.orig 2008-09-01 23:42:49.000000000 +0800 +++ heritage.h 2008-09-01 23:37:08.000000000 +0800 @@ -32,7 +32,7 @@ */ #include - +#include #include "vqueue.h" struct listen_sock { -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 1 15:50:06 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Sep 2008 15:50:06 -0000 Subject: [Varnish] #306: Throwing 503 Service Unavailable despite healthy backend in director Message-ID: <052.d8162ce5179a2e131a2a157f640bdab8@projects.linpro.no> #306: Throwing 503 Service Unavailable despite healthy backend in director ----------------------+----------------------------------------------------- Reporter: sensei | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: 2.0 Severity: normal | Keywords: backend polling ----------------------+----------------------------------------------------- I'm setting up Varnish with a random director and two backends, then make a request which is served from node1 and cached. Then I kill node1 and purge the cache, I then get a 503 on subsequent reququests even if there's a healthy backend in the director (node0). It refuses to use the other backend until the node1 is back up and marked as healthy. VCL: backend node0 { .host = "127.0.0.1"; .port = "80"; .probe = { .url = "/"; .timeout = 50 ms; .interval = 1s; .window = 10; .threshold = 8; } } backend node1 { .host = "81.29.85.44"; .port = "80"; .probe = { .url = "/"; .timeout = 100 ms; .interval = 1s; .window = 10; .threshold = 8; } } director cl1 random { { .backend = node1; .weight = 1; } { .backend = node0; .weight = 1; } } #director cl1 round-robin { # { .backend = node0; } # { .backend = node1; } #} sub vcl_recv { set req.backend = cl1; } So if I send a request and it goes to node1 and I then take node1 down and purge the cache, varnishd correctly marks it as sick, but it won't send subsequent requests to node0. This only happens for one node at a time. So if I in the example above were to take node0 down, and have node1 as healthy, it would not have this behaviour, but quite happily serve from node1. I haven't tried enough times to get any absolute statistical certainty, but it appears as this only applies to the backend defined first in the director. So if I swap them around in the above VCL to: director cl1 random { { .backend = node0; .weight = 1; } { .backend = node1; .weight = 1; } } it would pick up if node1 went down and only serve from node0 without any 503 errors, but not the other way around. This is on CentOS 4.6 with varnish-2.0-beta1. Had this in 3136 as well. GCC 3.4.6, kernel 2.6.9-67.0.15.plus.c4, glibc 2.3.4 for what it's worth. Hope this isn't too confusing! Cheers, sensei -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 1 16:01:15 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 01 Sep 2008 16:01:15 -0000 Subject: [Varnish] #306: Throwing 503 Service Unavailable despite healthy backend in director In-Reply-To: <052.d8162ce5179a2e131a2a157f640bdab8@projects.linpro.no> References: <052.d8162ce5179a2e131a2a157f640bdab8@projects.linpro.no> Message-ID: <061.72e4df7d12c20a69e3279c509873a414@projects.linpro.no> #306: Throwing 503 Service Unavailable despite healthy backend in director -----------------------------+---------------------------------------------- Reporter: sensei | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: backend polling | -----------------------------+---------------------------------------------- Comment (by sensei): I should also mention, I haven't been able to reproduce this with the round-robin director, it only appears to happen with random. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 2 04:21:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Sep 2008 04:21:21 -0000 Subject: [Varnish] #307: segfault in purge.hash() with empty string Message-ID: <049.9d5d4607a47297510c049a12c4b9f4d9@projects.linpro.no> #307: segfault in purge.hash() with empty string --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- in vcl_recv if you do this purge_hash(req.http.purgeurl); if purgeurl is empty, you get a segfault {{{ (gdb) bt #0 0x0000003482e76170 in strlen () from /lib64/libc.so.6 #1 0x0000003482eaece1 in regcomp () from /lib64/libc.so.6 #2 0x000000000040d37e in BAN_Add (cli=0x0, regexp=0x0, hash=1) at cache_ban.c:82 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 2 07:05:10 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Sep 2008 07:05:10 -0000 Subject: [Varnish] #304: Build fails on "undefined reference to `pthread_self'" In-Reply-To: <056.32202d51d9768ebe34e5fef966fb2ac6@projects.linpro.no> References: <056.32202d51d9768ebe34e5fef966fb2ac6@projects.linpro.no> Message-ID: <065.19bb0fd9f4e88909fc221d4f7ad3d0ca@projects.linpro.no> #304: Build fails on "undefined reference to `pthread_self'" ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: beta1 | ------------------------+--------------------------------------------------- Changes (by tfheen): * milestone: Varnish 2.0 code complete => Varnish 2.0 release Comment: Which OS/architecture is this on? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 2 07:06:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Sep 2008 07:06:35 -0000 Subject: [Varnish] #307: segfault in purge.hash() with empty string In-Reply-To: <049.9d5d4607a47297510c049a12c4b9f4d9@projects.linpro.no> References: <049.9d5d4607a47297510c049a12c4b9f4d9@projects.linpro.no> Message-ID: <058.43bc1a03e58b0f893a325fa612664464@projects.linpro.no> #307: segfault in purge.hash() with empty string --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * milestone: => Varnish 2.0 release Comment: Milestoning for 2.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 2 16:35:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Sep 2008 16:35:43 -0000 Subject: [Varnish] #308: Worker threads reported 0 Message-ID: <049.5aeeeeb54ccb74dfc40ac59a38ead667@projects.linpro.no> #308: Worker threads reported 0 --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- From varnishstat {{{ 0 . . N worker threads 1000 0.00 0.03 N worker threads created }}} No idea how to debug -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 2 19:05:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Sep 2008 19:05:22 -0000 Subject: [Varnish] #297: make check fails on test a00007, fedora9, i386 In-Reply-To: <052.1ca0026f49d62620dd6e25abccf80a62@projects.linpro.no> References: <052.1ca0026f49d62620dd6e25abccf80a62@projects.linpro.no> Message-ID: <061.aaf0961e7d600346c54ec45f0c7162b0@projects.linpro.no> #297: make check fails on test a00007, fedora9, i386 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: a00007 | --------------------+------------------------------------------------------- Changes (by ingvar): * status: closed => reopened * resolution: fixed => Comment: This is still not completely fixed in beta1 {{{ # TEST ././tests/a00007.vtc starting # TEST TCP reuse ## s1 Starting server ### s1 listen on 127.0.0.1:9080 (fd 3) ## c1 Starting client ## s1 Started on 127.0.0.1:9080 ## c1 Started ### c1 Connect to 127.0.0.1:9080 ### c1 Connected to 127.0.0.1:9080 fd is 5 #### c1 txreq| POST /1 HTTP/1.1\r\n #### c1 txreq| Content-Length: 10\r\n #### c1 txreq| \r\n #### c1 txreq| abcdefghi\n #### c1 txreq| \r\n ### c1 rxresp ## c1 Waiting for client ### s1 Accepted socket fd is 4 ### s1 rxreq #### s1 rxhdr| POST /1 HTTP/1.1\r\n #### s1 rxhdr| Content-Length: 10\r\n #### s1 rxhdr| \r\n #### s1 http[ 0] | POST #### s1 http[ 1] | /1 #### s1 http[ 2] | HTTP/1.1 #### s1 http[ 3] | Content-Length: 10 #### s1 body| abcdefghi\n #### s1 EXPECT req.url (/1) == /1 (/1) match #### s1 txresp| HTTP/1.1 200 Ok\r\n #### s1 txresp| Content-Length: 10\r\n #### s1 txresp| \r\n #### s1 txresp| 123456789\n #### s1 txresp| \r\n #### c1 rxhdr| HTTP/1.1 200 Ok\r\n #### c1 rxhdr| Content-Length: 10\r\n #### c1 rxhdr| \r\n #### c1 http[ 0] | HTTP/1.1 #### c1 http[ 1] | 200 #### c1 http[ 2] | Ok #### c1 http[ 3] | Content-Length: 10 #### c1 body| 123456789\n #### c1 txreq| POST /2 HTTP/1.1\r\n #### c1 txreq| Content-Length: 10\r\n #### c1 txreq| \r\n #### c1 txreq| ihgfedcba\n #### c1 txreq| \r\n ### c1 rxresp ### s1 rxreq #### s1 rxhdr| \r\n #### s1 rxhdr| POST /2 HTTP/1.1\r\n #### s1 rxhdr| Content-Length: 10\r\n #### s1 rxhdr| \r\n #### s1 http[ 0] | POST #### s1 http[ 1] | /2 #### s1 http[ 2] | HTTP/1.1 #### s1 http[ 3] | Content-Length: 10 #### s1 body| ihgfedcba\n #### s1 EXPECT req.url (/2) == /2 (/2) match #### s1 txresp| HTTP/1.1 200 Ok\r\n #### s1 txresp| Content-Length: 10\r\n #### s1 txresp| \r\n #### s1 txresp| 987654321\n #### s1 txresp| \r\n #### c1 rxhdr| \r\n #### c1 rxhdr| HTTP/1.1 200 Ok\r\n #### c1 rxhdr| Content-Length: 10\r\n #### c1 rxhdr| \r\n #### c1 http[ 0] | HTTP/1.1 #### c1 http[ 1] | 200 #### c1 http[ 2] | Ok #### c1 http[ 3] | Content-Length: 10 #### c1 body| 987654321\n ### c1 Closing fd 5 ## c1 Ending ## s1 Waiting for server ### s1 shutting fd 4 Assert error in server_thread(), vtc_server.c line 100: Condition((shutdown(fd, SHUT_WR)) == 0) not true. errno = 107 (Transport endpoint is not connected) /bin/sh: line 4: 25709 Aborted ./varnishtest -v ${dir}$tst FAIL: ./tests/a00007.vtc }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 2 21:56:28 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Sep 2008 21:56:28 -0000 Subject: [Varnish] #272: Assert error in vca_acct(), cache_acceptor.c line 173 In-Reply-To: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> References: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> Message-ID: <065.076ef1509ebc48f62cb8f29efdddaad1@projects.linpro.no> #272: Assert error in vca_acct(), cache_acceptor.c line 173 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Changes (by bonetruck2): * status: closed => reopened * resolution: wontfix => Comment: Using OpenBSD -current I was able to interpolate to a maximum value of 327. At 328+ the assert problem manifests again. Which file should have the ifdef? I assume it should be somewhere close to where the param struct is initialized and/or cmd line args are processed. Point me in the right direction and I'll give you a #if defined(__OpenBSD__) patch. thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 2 21:58:33 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Sep 2008 21:58:33 -0000 Subject: [Varnish] #272: Assert error in vca_acct(), cache_acceptor.c line 173 In-Reply-To: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> References: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> Message-ID: <065.4c19d617c112b863a98b4d7c21e0f66e@projects.linpro.no> #272: Assert error in vca_acct(), cache_acceptor.c line 173 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by bonetruck2): BTW, the previous post used the tech preview which I have running successfully now on OpenBSD: OpenBSD 4.4-beta (GENERIC) #990: Fri Jul 25 10:25:24 MDT 2008 deraadt at i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 2 22:01:26 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 02 Sep 2008 22:01:26 -0000 Subject: [Varnish] #304: Build fails on "undefined reference to `pthread_self'" In-Reply-To: <056.32202d51d9768ebe34e5fef966fb2ac6@projects.linpro.no> References: <056.32202d51d9768ebe34e5fef966fb2ac6@projects.linpro.no> Message-ID: <065.571ade79eeec108c01e2d53725f9bdf0@projects.linpro.no> #304: Build fails on "undefined reference to `pthread_self'" ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: beta1 | ------------------------+--------------------------------------------------- Comment (by bonetruck2): OpenBSD 4.4-beta (GENERIC) #990: Fri Jul 25 10:25:24 MDT 2008 deraadt at i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 02:08:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 02:08:48 -0000 Subject: [Varnish] #309: Varnish freezes if >1k of binary postdata is passed in Message-ID: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> #309: Varnish freezes if >1k of binary postdata is passed in ---------------------+------------------------------------------------------ Reporter: Fry-kun | Owner: des Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 2.0 Severity: normal | Keywords: ---------------------+------------------------------------------------------ To test, I run command-line curl as follows: curl 'http://localhost:2001/' --data-binary '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0' Varnish is running on port 2001, obviously. If 1 character from the data is removed (i.e. length of data becomes 1024), everything works. version: varnishd (varnish-2.0-tp2) also, varnishd (varnish-trunk) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 04:33:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 04:33:21 -0000 Subject: [Varnish] #310: WS_Reserve panic + error Message-ID: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> #310: WS_Reserve panic + error --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- Sep 3 00:20:20 varnish2 varnishd[25355]: Child (25376) died signal=6 Sep 3 00:20:20 varnish2 varnishd[25355]: Child (25376) Panic message: Assert error in WS_Reserve(), cache_ws.c line 156: Condition(ws->r == NULL) not true. thread = (cache-worker)sp = 0x14a64fc8 { fd = 1507, id = 1507, xid = 684175780, client = 72.81.232.3:1299, step = 0x8, handling = 0x0, err_code = 301, err_reason = (null), ws = 0x14a65038 { id = "sess", {s,f,r,e} = {0x14a65760,,+947,(nil),+32768}, }, worker = 0x2aaee1db0c10 { }, vcl = { srcname = { "/home/artur/wikia-beta.vcl", "Default", }, }, obj = 0x2aabad2f3000 { refcnt = 3, xid = 676411472, ws = 0x2aabad2f3028 { id = "obj", {s,f,r,e} = {0x2aabad2f3348,,+530,(nil),+31928}, }, http = { ws = 0x2aabad2f3028 { id = "obj", {s,f,r,e} = {0x2aabad2f3348,,+530,(nil),+31928}, }, hd = { "Date: Tue, 02 Sep 2008 20:44:22 GMT", "Server: Apache", "X -Powered-By: PHP/5.2.6", "Content-language: en", Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(7, sock) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(8, sock) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(9, cli_in) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(12, cli_out) Sep 3 00:20:20 varnish2 varnishd[25355]: child (28791) Started Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(9, (null)) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(12, (null)) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(7, (null)) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(8, (null)) Sep 3 00:20:20 varnish2 varnishd[25355]: Pushing vcls failed: dlopen(./vcl.1P9zoqAU.so): ./vcl.1P9zoqAU.so: cannot open shared object file: No such file or directory Sep 3 00:20:20 varnish2 varnishd[25355]: Child (28791) said Closed fds: 5 6 10 11 13 14 Sep 3 00:20:20 varnish2 varnishd[25355]: Child (28791) said Child starts Sep 3 00:20:20 varnish2 varnishd[25355]: Child (28791) said managed to mmap 15032385536 bytes of 15032385536 Sep 3 00:20:20 varnish2 varnishd[25355]: Child (28791) said Ready No core dump seem to have survived. Any suggestion for what to look for? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 04:38:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 04:38:07 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.dc40a39eaf6d6b1bee3cf5fb1ea995c3@projects.linpro.no> #310: WS_Reserve panic + error --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): {{{ Sep 3 00:20:20 varnish2 varnishd[25355]: Child (25376) died signal=6 Sep 3 00:20:20 varnish2 varnishd[25355]: Child (25376) Panic message: Assert error in WS_Reserve(), cache_ws.c line 156: Condition(ws->r == NULL) not true. thread = (cache-worker)sp = 0x14a64fc8 { fd = 1507, id = 1507, xid = 684175780, client = 72.81.232.3:1299, step = 0x8, handling = 0x0, err_code = 301, err_reason = (null), ws = 0x14a65038 { id = "sess", {s,f,r,e} = {0x14a65760,,+947,(nil),+32768}, }, worker = 0x2aaee1db0c10 { }, vcl = { srcname = { "/home/artur/wikia-beta.vcl", "Default", }, }, obj = 0x2aabad2f3000 { refcnt = 3, xid = 676411472, ws = 0x2aabad2f3028 { id = "obj", {s,f,r,e} = {0x2aabad2f3348,,+530,(nil),+31928}, }, http = { ws = 0x2aabad2f3028 { id = "obj", {s,f,r,e} = {0x2aabad2f3348,,+530,(nil),+31928}, }, hd = { "Date: Tue, 02 Sep 2008 20:44:22 GMT", "Server: Apache", "X-Powered-By: PHP/5.2.6", "Content-language: en", "X-Time-CPU-Time: 0.951 0.601", "Vary: Accept-Encoding,Cookie", "X-Vary-Options: Cookie;string-contains=wikicitiesUserID;string- contains=wikicities_session,Accept-Encoding;list-contains=gzip", "Cache-Control: s-maxage=18000, must-revalidate, max-age=0", "Last-modified: Wed, 27 Aug 2008 09:04:40 GMT", "Content-Encoding: gzip", "Content-Type: text/html; charset=utf-8", "Content-Length: 22225", "X-Cacheable: YES", "X-Cache: HIT", }, }, len = 22225, store = { 22225 { 1f 8b 08 00 00 00 00 00 00 03 ed bd fb 77 db 36 |.............w.6| 16 27 fe 73 72 4e ff 07 44 dd 36 c9 34 b2 5e 7e |.'.srN..D.6.4.^~| bf ba 8e ed 24 9e c9 c3 63 bb cd cc b6 3d 3a 94 |....$...c....=:.| 44 4b ac 29 51 43 51 76 dc d9 fe ef fb b9 78 10 |DK.)QCQv......x.| [22161 more] }, }, }, }, Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(7, sock) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(8, sock) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(9, cli_in) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(12, cli_out) Sep 3 00:20:20 varnish2 varnishd[25355]: child (28791) Started Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(9, (null)) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(12, (null)) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(7, (null)) Sep 3 00:20:20 varnish2 varnishd[25355]: mgt_child_inherit(8, (null)) Sep 3 00:20:20 varnish2 varnishd[25355]: Pushing vcls failed: dlopen(./vcl.1P9zoqAU.so): ./vcl.1P9zoqAU.so: cannot open shared object file: No such file or directory Sep 3 00:20:20 varnish2 varnishd[25355]: Child (28791) said Closed fds: 5 6 10 11 13 14 Sep 3 00:20:20 varnish2 varnishd[25355]: Child (28791) said Child starts Sep 3 00:20:20 varnish2 varnishd[25355]: Child (28791) said managed to mmap 15032385536 bytes of 15032385536 Sep 3 00:20:20 varnish2 varnishd[25355]: Child (28791) said Ready }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 04:45:32 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 04:45:32 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.c94e90d1397b5877ba4f5a1c3212f9cc@projects.linpro.no> #310: WS_Reserve panic + error --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): {{{ backend default { .host = "127.0.0.1"; .port = "80"; } backend wikia { .host = "xxxx"; .port = "80"; } backend armchair { .host = "xxxx"; .port = "80"; } backend gamewikis { .host = "xxxx"; .port = "80"; } backend images { .host = "xxxx"; .port = "80"; } # Below is a commented-out copy of the default VCL logic. If you # redefine any of these subroutines, the built-in logic will be # appended to your code. ## Called when a client request is received # sub vcl_recv { if (req.http.Accept-Encoding) { if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unkown algorithm remove req.http.Accept-Encoding; } } # clean out requests sent via curls -X mode and LWP if (req.url ~ "http://") { set req.url = regsub(req.url, "http://[^/]*",""); } if (req.request == "PURGE") { if (req.http.purgeurl) { purge_hash(req.http.purgeurl); error 200 "purged"; } else { error 503 "empty purgeurl"; } } if (req.url == "/lvscheck.html") { error 200 "varnish is okay"; } if(req.http.host ~ "^(nwn|oblivion|meta|war|gw)$") { set req.backend = wikia; } elsif(req.http.host ~ "(gw.wikia.com|gamewikis.org)$") { set req.backend = gamewikis; } elsif(req.http.host ~ "^siwiki.sportsillustrated.cnn.com$") { set req.backend = armchair; } elsif(req.http.host ~ "^thirdturn.armchairgm.com$") { set req.backend = wikia; } elsif(req.http.host ~ "armchairgm.com$") { set req.backend = armchair; } elsif(req.http.host ~ "images.wikia.com") { set req.backend = images; } else { set req.backend = wikia; } if (req.url ~ "/__utm.gif") { set req.url = "/__utm.gif"; } if (req.url ~ "/rx") { error 200 "not serving this"; } if (req.http.host == "216.151.156.11") { set req.http.origurl = req.url; } if (req.request != "GET" && req.request != "HEAD" && req.request != "PURGE") { pipe; } if (req.http.Expect) { pipe; } if (req.http.User-Agent ~ "Opera") { pipe; } if (req.http.Cookie ~ "UserID") { set req.http.tmp_userid = regsuball(req.http.Cookie, "(.*?)(^|;|\s)(.*UserID=[^;]*).*", "\3; "); } else { set req.http.tmp_userid = " "; } if (req.http.Cookie ~ "UserName") { set req.http.tmp_username = regsuball(req.http.Cookie, "(.*?)(^|;|\s)(.*UserName=[^;]*).*", "\3; "); } else { set req.http.tmp_username = " "; } if (req.http.Cookie ~ "session") { set req.http.tmp_session = regsub(req.http.Cookie, "(.*)(^|;|\s)(.*session=[^;]*).*", "\3; "); } else { set req.http.tmp_session = " "; } if (req.http.Cookie ~ "Token") { set req.http.tmp_token = regsub(req.http.Cookie, "(.*)(^|;|\s)(.*Token=[^;]*).*", "\3; "); } else { set req.http.tmp_token = " "; } if (req.http.Cookie ~ "LoggedOut") { set req.http.tmp_loggedout = regsub(req.http.Cookie, "(.*)(^|;|\s)(.*LoggedOut=[^;]*).*", "\3; "); } else { set req.http.tmp_loggedout = " "; } set req.http.Cookie = ""; set req.http.Cookie = req.http.tmp_userid " ; " req.http.tmp_session " ; " req.http.tmp_token " ; " req.http.tmp_username " ; " req.http.tmp_loggedout; remove req.http.tmp_userid; remove req.http.tmp_session; remove req.http.tmp_token; remove req.http.tmp_loggedout; remove req.http.tmp_username; if (req.http.Authenticate) { pass; } lookup; } sub vcl_hash { set req.hash += req.url; set req.hash += req.http.host; hash; } # ## Called when entering pipe mode # #sub vcl_pipe { # pipe; #} # ## Called when entering pass mode # #sub vcl_pass { # set resp.http.foo = "x"; # pass; #} # ## Called when entering an object into the cache # # ## Called when the requested object was found in the cache # sub vcl_hit { if (req.request == "PURGE") { error 200 "purged"; } if (!obj.cacheable) { pass; } if (obj.http.X-Cache == "MISS") { set obj.http.X-Cache = "HIT"; } deliver; } # ## Called when the requested object was not found in the cache # sub vcl_miss { if (req.request == "PURGE") { # nuke; error 200 "purged"; } fetch; } # ## Called when the requested object has been retrieved from the ## backend, or the request to the backend has failed # sub vcl_fetch { set obj.http.X-Cache = "MISS"; # this is the old wow ip, so issue redirect if (req.http.host == "216.151.156.11") { set obj.http.origurl = req.http.origurl; } if (!obj.cacheable) { set obj.http.X-Cacheable = "NO:Not-Cacheable"; pass; } if (obj.http.Cache-Control ~ "private") { if(req.http.Cookie ~"(UserID|_session)") { set obj.http.X-Cacheable = "NO:Got Session"; } else { set obj.http.X-Cacheable = "NO:Cache- Control=private"; } pass; } if (obj.http.Set-Cookie ~ "(UserID|_session)") { set obj.http.X-Cacheable = "NO:Set-Cookie"; pass; } set obj.http.X-Cacheable = "YES"; set obj.grace = 10s; deliver; } sub vcl_prefetch { pass; } # # ## Called before a cached object is delivered to the client # sub vcl_deliver { set resp.http.X-Served-By = "varnish2"; # this is the old wow ip, so issue redirect if (resp.http.origurl) { set resp.http.Location = regsub(resp.http.origurl, "^" , "http://www.wowwiki.com"); set resp.status = 301; set resp.response = "Moved Permanently"; deliver; } set resp.http.Cache-Control = "private, s-maxage=0, max-age=0, must- revalidate"; set resp.http.Expires = "Thu, 01 Jan 1970 00:00:00 GMT"; if(!resp.http.Vary) { set resp.http.Vary = "Accept-Encoding,Cookie"; } deliver; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 05:01:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 05:01:35 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.98a73ca68f5b6a179ef10fb442c4de4d@projects.linpro.no> #310: WS_Reserve panic + error --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): started as such {{{ bin/varnishd/varnishd -w 500,2000 -a :80 -T localhost:6082 -f /home/artur /wikia-beta.vcl -u varnish -g varnish -s file,/var/lib/varnish/varnish_storage.bin,14G -p obj_workspace=32768 -p sess_workspace=32768 -p thread_pools=2 -p listen_depth=8192 -p ping_interval=0 -p log_hashstring=on -F }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 07:12:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 07:12:50 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 Message-ID: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- varnishtest fails at the exact same point every time on ppc64. Probably a bug then. Tested on Fedora 9 and SuSE SLES9. Here's the output of varnishtest -v: {{{ # TEST tests/c00005.vtc starting # TEST Test simple ACL ## s1 Starting server ### s1 listen on 127.0.0.1:9080 (fd 3) ## v1 Launch ## s1 Started on 127.0.0.1:9080 ### v1 CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/__v1 -a '127.0.0.1:9081' -T 127.0.0.1:9001 ### v1 opening CLI connection #### v1 debug| storage_file: filename: ./varnish.5krYiK (unlinked) size 264 MB.\n #### v1 debug| mgt_child_inherit(3, storage_file)\n #### v1 debug| Using old SHMFILE\n #### v1 debug| Notice: locking SHMFILE in core failed: Operation not permitted\n #### v1 debug| Debugging mode, enter "start" to start child\n ### v1 CLI connection fd = 4 #### v1 CLI TX| vcl.inline vcl1 "backend s1 { .host = \"127.0.0.1\"; .port = \"9080\"; }\n\n\tacl acl1 {\n\t\t\"localhost\";\n\t}\n\n\tsub vcl_recv {\n\t\tif (client.ip ~ acl1) {\n\t\t\tset req.url = \"/\";\n\t\t}\n\t}\n" #### v1 CLI RX| VCL compiled. ### v1 CLI STATUS 200 #### v1 CLI TX| vcl.use vcl1 ### v1 CLI STATUS 200 ## v1 Start #### v1 CLI TX| start #### v1 debug| mgt_child_inherit(8, sock)\n #### v1 debug| mgt_child_inherit(9, cli_in)\n #### v1 debug| mgt_child_inherit(12, cli_out)\n #### v1 debug| child (9895) Started\n #### v1 debug| mgt_child_inherit(9, (null))\n #### v1 debug| mgt_child_inherit(12, (null))\n #### v1 debug| mgt_child_inherit(8, (null))\n ### v1 CLI STATUS 200 #### v1 CLI TX| debug.xid 1000 #### v1 debug| Child (9895) said Closed fds: 5 6 7 10 11 13 14\n #### v1 debug| Child (9895) said Child starts\n #### v1 debug| Child (9895) said managed to mmap 277008384 bytes of 277008384\n #### v1 debug| Child (9895) said Ready\n #### v1 CLI RX| XID is 1000\n ### v1 CLI STATUS 200 ## c1 Starting client ## c1 Started ### c1 Connect to 127.0.0.1:9081 ### c1 Connected to 127.0.0.1:9081 fd is 8 #### c1 txreq| GET foo HTTP/1.1\r\n #### c1 txreq| \r\n ### c1 rxresp ## c1 Waiting for client ### s1 Accepted socket fd is 9 ### s1 rxreq #### s1 rxhdr| GET foo HTTP/1.1\r\n #### s1 rxhdr| X-Varnish: 1001\r\n #### s1 rxhdr| X-Forwarded-For: 127.0.0.1\r\n #### s1 rxhdr| Host: 127.0.0.1\r\n #### s1 rxhdr| \r\n #### s1 http[ 0] | GET #### s1 http[ 1] | foo #### s1 http[ 2] | HTTP/1.1 #### s1 http[ 3] | X-Varnish: 1001 #### s1 http[ 4] | X-Forwarded-For: 127.0.0.1 #### s1 http[ 5] | Host: 127.0.0.1 ---- s1 EXPECT req.url (foo) == / (/) failed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 07:17:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 07:17:14 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 In-Reply-To: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> References: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> Message-ID: <061.8cd967720ed576f39a28f465435a3b35@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): Sounds like a "interesting" IP configuration, if 127.0.0.1 does not match "localhost". Try replacing 'localhost' in the ACL's with 127.0.0.1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 07:20:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 07:20:57 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.4cfbf7a3d8f8b2a07b1918c4f2b02b63@projects.linpro.no> #310: WS_Reserve panic + error --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: It looks like you ran out of workspace for http modifications, as far as I can tell you need to increase sess_workspace param. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 07:22:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 07:22:30 -0000 Subject: [Varnish] #309: Varnish freezes if >1k of binary postdata is passed in In-Reply-To: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> References: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> Message-ID: <062.6a5fe576f3fe57dc29a873679e2a092d@projects.linpro.no> #309: Varnish freezes if >1k of binary postdata is passed in ---------------------+------------------------------------------------------ Reporter: Fry-kun | Owner: des Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Old description: > To test, I run command-line curl as follows: > curl 'http://localhost:2001/' --data-binary > '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0' > > Varnish is running on port 2001, obviously. If 1 character from the data > is removed (i.e. length of data becomes 1024), everything works. > > version: varnishd (varnish-2.0-tp2) > also, varnishd (varnish-trunk) New description: To test, I run command-line curl as follows: {{{ curl 'http://localhost:2001/' --data-binary '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0' }}} Varnish is running on port 2001, obviously. If 1 character from the data is removed (i.e. length of data becomes 1024), everything works. version: varnishd (varnish-2.0-tp2) also, varnishd (varnish-trunk) Comment (by phk): When you say "freezes" what do you mean ? THat you don't get a reply to this request ? That it doesn't reply to CLI pings ? Does varnishlog record the transaction ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 07:25:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 07:25:46 -0000 Subject: [Varnish] #304: Build fails on "undefined reference to `pthread_self'" In-Reply-To: <056.32202d51d9768ebe34e5fef966fb2ac6@projects.linpro.no> References: <056.32202d51d9768ebe34e5fef966fb2ac6@projects.linpro.no> Message-ID: <065.9af205471b908408503cab95f68c4625@projects.linpro.no> #304: Build fails on "undefined reference to `pthread_self'" ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: fixed Keywords: beta1 | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in r3158 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 07:31:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 07:31:43 -0000 Subject: [Varnish] #272: Assert error in vca_acct(), cache_acceptor.c line 173 In-Reply-To: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> References: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> Message-ID: <065.2d045fad5af3fcdb859be1ea6e16ef25@projects.linpro.no> #272: Assert error in vca_acct(), cache_acceptor.c line 173 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: After 2.0 Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * milestone: => After 2.0 Comment: The workaround is to set parameter "send_timeout" to a value that the kernel will accept, the default is presently 600. I will not change the default this close to 2.0, but we can revisit the default after the release. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 07:33:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 07:33:39 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 In-Reply-To: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> References: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> Message-ID: <061.672dcf78f71a1d3986f9c945bf2efd58@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by ingvar): Fails exactly the same way if one either fixes in /etc/hosts or changes the acl to 127.0.0.1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 07:37:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 07:37:22 -0000 Subject: [Varnish] #305: 2.0 beta1 cannot be built on MacOSX In-Reply-To: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no> References: <052.c057b98f233565be42c7e3ad12a65caa@projects.linpro.no> Message-ID: <061.1ee854156d0d719ba1e20d78939b7462@projects.linpro.no> #305: 2.0 beta1 cannot be built on MacOSX ---------------------+------------------------------------------------------ Reporter: 191919 | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: build | Version: trunk Severity: blocker | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in r3159 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 09:29:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 09:29:39 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 In-Reply-To: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> References: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> Message-ID: <061.e313b065af778aad2c5d5d22324bef6c@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by ingvar): I added a default backend, and baked c00005.vtc into the following vcl. Then ran varnishd -f foo.vcl -C on ppc64, and attached the output here. {{{ backend default { .host = "127.0.0.1"; .port = "80"; } acl acl1 { "localhost"; } acl acl2 { ! "localhost"; } sub vcl_recv { if (client.ip ~ acl1) { set req.url = "/"; } if (client.ip ~ acl2) { set req.url = "/"; } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 13:40:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 13:40:50 -0000 Subject: [Varnish] #312: No way to access backend health from VCL Message-ID: <052.2440980d0fe095664f2e83d64877361c@projects.linpro.no> #312: No way to access backend health from VCL ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- VCL does not, at the moment, have any way to check for the backend health. It's defined in the VCL language, but its implementation is missing/INCOMPL(). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 14:42:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 14:42:37 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.954bb172f1303d2a6e437e560e343ae1@projects.linpro.no> #310: WS_Reserve panic + error --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by sky): * status: closed => reopened * resolution: worksforme => Comment: The path it took was via recv/hash/hit/deliver -- the sess_workspace is already 32kb, there is nothing very different from all the other requests. I am rather surprised how it could eat up 32768 bytes of work space for a hit The second bug would be failing to reload the vcl after the crash. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 20:36:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 20:36:55 -0000 Subject: [Varnish] #309: Varnish freezes if >1k of binary postdata is passed in In-Reply-To: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> References: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> Message-ID: <062.a59f98093dfb0ae5767587664d2ebe46@projects.linpro.no> #309: Varnish freezes if >1k of binary postdata is passed in ---------------------+------------------------------------------------------ Reporter: Fry-kun | Owner: des Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by Fry-kun): By "freezes" I mean it hangs there for several seconds instead of sending a reply. Curl reports empty reply after 7 seconds. See curl log & varnishlog below: {{{ $ time curl -v 'http://localhost:2001/' --data-binary '0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0' * About to connect() to localhost port 2001 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2001 (#0) > POST / HTTP/1.1 > User-Agent: curl/7.18.2-CVS (x86_64-unknown-linux-gnu) libcurl/7.18.2-CVS OpenSSL/0.9.8b zlib/1.2.3 > Host: localhost:2001 > Accept: */* > Content-Length: 1025 > Content-Type: application/x-www-form-urlencoded > Expect: 100-continue > < HTTP/1.1 100 Continue < Date: Wed, 03 Sep 2008 20:33:37 GMT < X-Varnish: 1298835500 < Age: 0 < Via: 1.1 varnish < Connection: keep-alive * Empty reply from server * Connection #0 to host localhost left intact curl: (52) Empty reply from server * Closing connection #0 curl -v 'http://localhost:2001/' --data-binary 0.01s user 0.01s system 0% cpu 7.016 total }}} {{{ 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1220474013 8 SessionOpen c 127.0.0.1 37002 0.0.0.0:2001 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1220474016 8 ReqStart c 127.0.0.1 37002 1298835500 8 RxRequest c POST 8 RxURL c / 8 RxProtocol c HTTP/1.1 8 RxHeader c User-Agent: curl/7.18.2-CVS (x86_64-unknown-linux- gnu) libcurl/7.18.2-CVS OpenSSL/0.9.8b zlib/1.2.3 8 RxHeader c Host: localhost:2001 8 RxHeader c Accept: */* 8 RxHeader c Content-Length: 1025 8 RxHeader c Content-Type: application/x-www-form-urlencoded 8 RxHeader c Expect: 100-continue 8 VCL_call c recv 8 VCL_return c pass 8 VCL_call c pass 8 VCL_return c pass 9 BackendClose - default 9 BackendOpen b default 127.0.0.1 52239 127.0.0.1 1089 9 TxRequest b POST 9 TxURL b / 9 TxProtocol b HTTP/1.1 9 TxHeader b User-Agent: curl/7.18.2-CVS (x86_64-unknown-linux- gnu) libcurl/7.18.2-CVS OpenSSL/0.9.8b zlib/1.2.3 9 TxHeader b Host: localhost:2001 9 TxHeader b Accept: */* 9 TxHeader b Content-Length: 1025 9 TxHeader b Content-Type: application/x-www-form-urlencoded 9 TxHeader b Expect: 100-continue 9 TxHeader b X-Varnish: 1298835500 9 TxHeader b X-Forwarded-For: 127.0.0.1 9 RxProtocol b HTTP/1.1 9 RxStatus b 100 9 RxResponse b Continue 8 ObjProtocol c HTTP/1.1 8 ObjStatus c 100 8 ObjResponse c Continue 9 BackendReuse b default 8 TTL c 1298835500 RFC 3600 1220474017 0 0 0 0 8 VCL_call c fetch 8 VCL_return c pass 8 Length c 0 8 VCL_call c deliver 8 VCL_return c deliver 8 TxProtocol c HTTP/1.1 8 TxStatus c 100 8 TxResponse c Continue 8 TxHeader c Date: Wed, 03 Sep 2008 20:33:37 GMT 8 TxHeader c X-Varnish: 1298835500 8 TxHeader c Age: 0 8 TxHeader c Via: 1.1 varnish 8 TxHeader c Connection: keep-alive 8 ReqEnd c 1298835500 1220474015.862066031 1220474017.862364769 0.000212431 2.000207663 0.000091076 0 StatAddr - 127.0.0.1 0 60 3 3 0 0 3 405 0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1220474019 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1220474022 8 SessionClose c timeout 8 StatSess c 127.0.0.1 37002 2 1 1 0 0 1 135 0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1220474025 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1220474028 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 20:46:03 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 20:46:03 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 In-Reply-To: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> References: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> Message-ID: <061.cb1d6399121a2e718938d43e24b72f6d@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by ingvar): I diffed the output of varnishd -f foo.vcl -C on i386 and ppc64. It differs. I would think that that code should be platform neutral. {{{ --- foo.c.i386 2008-09-03 22:38:06.000000000 +0200 +++ foo.c.ppc64 2008-09-03 22:38:38.000000000 +0200 @@ -297,7 +297,7 @@ static const unsigned char sockaddr0[17] = { 16, /* Length */ - 2, 0, 0, 80, 127, 0, 0, 1, + 0, 2, 0, 80, 127, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0 }; @@ -838,7 +838,6 @@ " if (client.ip ~ acl1) { set req.url = \"/\"; }\n" " if (client.ip ~ acl2) { set req.url = \"/\"; }\n" "}\n" - "\n" "", /* "Default"*/ "/*-\n" }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 20:53:24 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 20:53:24 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 In-Reply-To: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> References: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> Message-ID: <061.8676f50daea6636ec33586dba00ab058@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): No, this is as it should be, the byte-string is a platfrom specific "struct sockaddr" and the relevant platforms alignment and endianess controls. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 20:58:54 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 20:58:54 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 In-Reply-To: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> References: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> Message-ID: <061.ba9df460a38ccfbcdb47ad9ef2c598dc@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): Try this change: {{{ Index: tests/c00005.vtc =================================================================== --- tests/c00005.vtc (revision 3162) +++ tests/c00005.vtc (working copy) @@ -11,7 +11,7 @@ txresp -body "2222\n" } -start -varnish v1 -vcl+backend { +varnish v1 -arg "-p vcl_trace=on" -vcl+backend { acl acl1 { "localhost"; } }}} and then capture with {{{varnishlog -n /tmp/__v1}}} to see where it goes in the VCL code and why it does not hit the ACL -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 21:41:44 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 21:41:44 -0000 Subject: [Varnish] #309: Varnish freezes if >1k of binary postdata is passed in In-Reply-To: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> References: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> Message-ID: <062.2b81b20450a12799b98630c5aa017832@projects.linpro.no> #309: Varnish freezes if >1k of binary postdata is passed in ---------------------+------------------------------------------------------ Reporter: Fry-kun | Owner: des Type: defect | Status: new Priority: high | Milestone: Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by Fry-kun): I just noticed that changing the POST setting from pass to pipe seems to fix the problem. Here's my configuration: {{{ backend default { .host = "127.0.0.1"; .port = "1089"; # was "8080"; } acl purge { "localhost"; "192.168.1.0"/16; } sub vcl_recv { # Handle special requests if (req.request != "GET" && req.request != "HEAD") { # POST - Logins and edits if (req.request == "POST") { pass; #pipe; } # PURGE - The CacheFu product can invalidate updated URLs if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } lookup; } } # Don't cache authenticated requests if (req.http.Cookie && req.http.Cookie ~ "__ac(|_(name|password|persistent))=") { # Force lookup of specific urls unlikely to need protection if (req.url ~ "\.(js|css)") { unset req.http.cookie; lookup; } pass; } if (req.http.Cookie) { unset req.http.cookie; lookup; } # The default vcl_recv is used from here. } # Do the PURGE thing sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged"; } } sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache"; } } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 3 21:42:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 03 Sep 2008 21:42:01 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 In-Reply-To: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> References: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> Message-ID: <061.a88c4cc4abd8d3f287133e47647dd89e@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by ingvar): varnishlog output {{{ 0 WorkThread - 0x4609fab0 start 0 CLI - Rd vcl.load vcl1 ./vcl.1P9zoqAU.so 0 CLI - Wr 0 200 Loaded "./vcl.1P9zoqAU.so" as "vcl1" 0 CLI - Rd vcl.use vcl1 0 CLI - Wr 0 200 0 CLI - Rd start 0 Debug - "Acceptor is epoll" 0 CLI - Wr 0 200 0 WorkThread - 0x57250ab0 start 0 CLI - Rd debug.xid 1000 0 CLI - Wr 0 200 XID is 1000 0 WorkThread - 0x57650ab0 start 0 WorkThread - 0x57a50ab0 start 0 WorkThread - 0x57e50ab0 start 0 WorkThread - 0x58250ab0 start 7 SessionOpen c 127.0.0.1 35212 127.0.0.1:9081 7 ReqStart c 127.0.0.1 35212 1001 7 RxRequest c GET 7 RxURL c foo 7 RxProtocol c HTTP/1.1 7 VCL_call c recv 7 VCL_trace c 1 7.22 7 VCL_trace c 2 8.21 7 VCL_trace c 4 11.9 7 VCL_trace c 5 41.14 7 VCL_trace c 6 42.9 7 VCL_trace c 14 52.5 7 VCL_trace c 15 52.9 7 VCL_trace c 17 56.5 7 VCL_trace c 18 56.9 7 VCL_trace c 21 60.5 7 VCL_trace c 22 60.9 7 VCL_trace c 23 60.35 7 VCL_trace c 25 64.5 7 VCL_return c lookup 7 VCL_call c hash 7 VCL_trace c 28 75.14 7 VCL_trace c 29 77.9 7 VCL_trace c 31 79.12 7 VCL_return c hash 7 VCL_call c miss 7 VCL_trace c 36 92.14 7 VCL_return c fetch 10 BackendOpen b s1 127.0.0.1 35213 127.0.0.1 9080 10 TxRequest b GET 10 TxURL b foo 10 TxProtocol b HTTP/1.1 10 TxHeader b X-Varnish: 1001 10 TxHeader b X-Forwarded-For: 127.0.0.1 10 TxHeader b Host: 127.0.0.1 10 BackendClose b s1 7 VCL_call c error 7 VCL_trace c 48 123.15 7 VCL_return c deliver 7 Length c 447 7 VCL_call c deliver 7 VCL_trace c 44 107.17 7 VCL_return c deliver 7 TxProtocol c HTTP/1.1 7 TxStatus c 503 7 TxResponse c Service Unavailable 7 TxHeader c Server: Varnish 7 TxHeader c Retry-After: 0 7 TxHeader c Content-Type: text/html; charset=utf-8 7 TxHeader c Content-Length: 447 7 TxHeader c Date: Wed, 03 Sep 2008 22:31:11 GMT 7 TxHeader c X-Varnish: 1001 7 TxHeader c Age: 0 7 TxHeader c Via: 1.1 varnish 7 TxHeader c Connection: keep-alive 7 ReqEnd c 1001 1220481071.941648960 1220481071.945290089 0.067060947 0.003546000 0.000095129 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 5 03:09:51 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 05 Sep 2008 03:09:51 -0000 Subject: [Varnish] #313: beta1 fails tests on Solaris Message-ID: <054.d194a5babde100e802ea9a215eefe550@projects.linpro.no> #313: beta1 fails tests on Solaris ----------------------+----------------------------------------------------- Reporter: postwait | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- Looks like: REPORT(LOG_ERR, "mgt_child_inherit(%d, %s)", fd, what); In mgt_child_inherit(int fd, const char *what) in bin/varnishd/mgt_child.c is throwing a wrench in the management communication channel. Not sure how this doesn't break all platforms though. If ou comment that line out, all tests pass (at least for me). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 5 14:17:19 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 05 Sep 2008 14:17:19 -0000 Subject: [Varnish] #313: beta1 fails tests on Solaris In-Reply-To: <054.d194a5babde100e802ea9a215eefe550@projects.linpro.no> References: <054.d194a5babde100e802ea9a215eefe550@projects.linpro.no> Message-ID: <063.180e0ff742a0190ffb8d5daab054dbaa@projects.linpro.no> #313: beta1 fails tests on Solaris ----------------------+----------------------------------------------------- Reporter: postwait | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: varnishd | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This is an corruption of the beta1 release, that line is not in SVN. Most likely the reason it causes a failure is because the messages causes buffering on the stderr/stdout and the CLI response fails. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 7 16:52:08 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 07 Sep 2008 16:52:08 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.543c9ea04e35b4926686330d97a61975@projects.linpro.no> #310: WS_Reserve panic + error --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by sky): {{{ (gdb) bt #0 0x0000003482e30055 in raise () from /lib64/libc.so.6 #1 0x0000003482e31af0 in abort () from /lib64/libc.so.6 #2 0x0000000000419bc2 in pan_ic (func=, file=, line=, cond=, err=64, xxx=) at cache_panic.c:325 #3 0x0000000000426054 in WS_Reserve (ws=0x2aab8d8b9028, bytes=0) at cache_ws.c:156 #4 0x0000000000420ce6 in vrt_assemble_string (hp=dwarf2_read_address: Corrupted DWARF expression.) at cache_vrt.c:131 #5 0x0000000000422af5 in VRT_SetHdr (sp=0xb122b68, where=, hdr=0x2aae30291417 "\bX-Cache:", p=0x2aae30291426 "HIT") at cache_vrt.c:179 #6 0x00002aae302903b1 in ?? () #7 0x00002aaeee5c4c10 in ?? () #8 0x000000000b122b68 in ?? () #9 0x000000000b122b68 in ?? () #10 0x000000000041f466 in VCL_hit_method (sp=0xb122b68) at ../../include/vcl_returns.h:42 #11 0x000000000040dfd8 in cnt_hit (sp=0xb122b68) at cache_center.c:518 #12 0x000000000040f8d4 in CNT_Session (sp=0x2aaeee5c2b90) at steps.h:40 #13 0x000000000041b761 in wrk_do_cnt_sess (w=0x2aaeee5c4c10, priv=) at cache_pool.c:363 #14 0x000000000041a8a7 in wrk_thread (priv=0x3744e20) at cache_pool.c:276 #15 0x0000003483e062f7 in start_thread () from /lib64/libpthread.so.0#16 0x0000003482ece85d in clone () from /lib64/libc.so.6 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 7 16:59:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 07 Sep 2008 16:59:37 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.9ca2765c52c1ffded388683bf45202ee@projects.linpro.no> #310: WS_Reserve panic + error ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * owner: des => phk * status: reopened => new * component: build => varnishd * milestone: => After 2.0 Comment: I guess this is a "Ah-ha" bug. We cannot safely assign a string variable that is built on the object workspace in vcl_hit{} because the object is not locked. If two worker threads tries to do it at the same time, they will collide like we see here. I don't think this will be fixed for 2.0, it will have to be an errata. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 01:22:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 01:22:20 -0000 Subject: [Varnish] #314: undefined reference to `pthread_self' Message-ID: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> #314: undefined reference to `pthread_self' ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Keywords: ------------------------+--------------------------------------------------- Just like ticket 304, beta1 build fails in more locations. I added ${PTHREAD_LIBS} to the Makefile.am files *_LDADD for varnishlog, varnishnca, and varnishstat. Then ran autogen.sh, configure and then compiled successfully. OpenBSD 4.4-beta (GENERIC) #990: Fri Jul 25 10:25:24 MDT 2008 deraadt at i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC Let me know if you need more information. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 07:21:09 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 07:21:09 -0000 Subject: [Varnish] #314: undefined reference to `pthread_self' In-Reply-To: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> References: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> Message-ID: <065.5756d10f3469bf63c2dffe3d2b6efa64@projects.linpro.no> #314: undefined reference to `pthread_self' ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by phk): Can you send us your patch ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 07:28:42 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 07:28:42 -0000 Subject: [Varnish] #309: Varnish freezes if >1k of binary postdata is passed in In-Reply-To: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> References: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> Message-ID: <062.830d86df07499d32801c9ecddaedb3d6@projects.linpro.no> #309: Varnish freezes if >1k of binary postdata is passed in ---------------------+------------------------------------------------------ Reporter: Fry-kun | Owner: des Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by tfheen): * milestone: => Varnish 2.0 release Comment: Target for 2.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 07:29:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 07:29:50 -0000 Subject: [Varnish] #309: Varnish freezes if >1k of binary postdata is passed in In-Reply-To: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> References: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> Message-ID: <062.d2a4ea795e1ab6556df617392e301a6f@projects.linpro.no> #309: Varnish freezes if >1k of binary postdata is passed in ---------------------+------------------------------------------------------ Reporter: Fry-kun | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * owner: des => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 07:52:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 07:52:04 -0000 Subject: [Varnish] #307: segfault in purge.hash() with empty string In-Reply-To: <049.9d5d4607a47297510c049a12c4b9f4d9@projects.linpro.no> References: <049.9d5d4607a47297510c049a12c4b9f4d9@projects.linpro.no> Message-ID: <058.2d54f4f84a9c6151a795a0b6a2157119@projects.linpro.no> #307: segfault in purge.hash() with empty string --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed (properly) in commit 3167. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 07:52:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 07:52:49 -0000 Subject: [Varnish] #290: Make dir in /usr/local/var/varnish In-Reply-To: <054.a171d91cbb7594e23ea750517981ab8a@projects.linpro.no> References: <054.a171d91cbb7594e23ea750517981ab8a@projects.linpro.no> Message-ID: <063.ff4cbff13338d8df81a48ca649f4d795@projects.linpro.no> #290: Make dir in /usr/local/var/varnish ----------------------+----------------------------------------------------- Reporter: The_ZoRo | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): Which OS/platform are you on? Have you actually run make install? That should create the directory for you. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 09:16:42 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 09:16:42 -0000 Subject: [Varnish] #297: make check fails on test a00007, fedora9, i386 In-Reply-To: <052.1ca0026f49d62620dd6e25abccf80a62@projects.linpro.no> References: <052.1ca0026f49d62620dd6e25abccf80a62@projects.linpro.no> Message-ID: <061.1aecdf9cf836cda256d0b6a3f44dda44@projects.linpro.no> #297: make check fails on test a00007, fedora9, i386 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: a00007 | --------------------+------------------------------------------------------- Comment (by ingvar): I'm unable to reproduce this error on my system now, so for my part, this bug can be closed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 09:50:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 09:50:22 -0000 Subject: [Varnish] #312: No way to access backend health from VCL In-Reply-To: <052.2440980d0fe095664f2e83d64877361c@projects.linpro.no> References: <052.2440980d0fe095664f2e83d64877361c@projects.linpro.no> Message-ID: <061.cadb4d894f5c56f5245cb30c7b9d4330@projects.linpro.no> #312: No way to access backend health from VCL ----------------------+----------------------------------------------------- Reporter: tfheen | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: You can now see whether the backend health is good with req.backend.health. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 09:54:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 09:54:53 -0000 Subject: [Varnish] #297: make check fails on test a00007, fedora9, i386 In-Reply-To: <052.1ca0026f49d62620dd6e25abccf80a62@projects.linpro.no> References: <052.1ca0026f49d62620dd6e25abccf80a62@projects.linpro.no> Message-ID: <061.4c06d4dee92898ea03e5ef2f7fa636ab@projects.linpro.no> #297: make check fails on test a00007, fedora9, i386 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: a00007 | --------------------+------------------------------------------------------- Changes (by tfheen): * status: reopened => closed * resolution: => fixed Comment: Closing, presumably it's been fixed. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 13:13:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 13:13:48 -0000 Subject: [Varnish] #314: undefined reference to `pthread_self' In-Reply-To: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> References: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> Message-ID: <065.e46b175c520bb4d3f61e5900d3390b85@projects.linpro.no> #314: undefined reference to `pthread_self' ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by bonetruck2): --- bin/varnishlog/Makefile.am.orig Sun Sep 7 20:36:16 2008 +++ bin/varnishlog/Makefile.am Sun Sep 7 20:35:46 2008 @@ -11,4 +11,5 @@ varnishlog_SOURCES = varnishlog.c varnishlog_LDADD = \ $(top_builddir)/lib/libvarnish/libvarnish.la \ $(top_builddir)/lib/libvarnishcompat/libvarnishcompat.la \ - $(top_builddir)/lib/libvarnishapi/libvarnishapi.la + $(top_builddir)/lib/libvarnishapi/libvarnishapi.la \ + ${PTHREAD_LIBS} --- bin/varnishncsa/Makefile.am.orig Sun Sep 7 20:46:17 2008 +++ bin/varnishncsa/Makefile.am Sun Sep 7 20:47:10 2008 @@ -11,4 +11,5 @@ varnishncsa_SOURCES = varnishncsa.c varnishncsa_LDADD = \ $(top_builddir)/lib/libvarnish/libvarnish.la \ $(top_builddir)/lib/libvarnishcompat/libvarnishcompat.la \ - $(top_builddir)/lib/libvarnishapi/libvarnishapi.la + $(top_builddir)/lib/libvarnishapi/libvarnishapi.la \ + ${PTHREAD_LIBS} --- bin/varnishstat/Makefile.am.orig Sun Sep 7 20:58:11 2008 +++ bin/varnishstat/Makefile.am Sun Sep 7 20:59:09 2008 @@ -12,4 +12,4 @@ varnishstat_LDADD = \ $(top_builddir)/lib/libvarnish/libvarnish.la \ $(top_builddir)/lib/libvarnishcompat/libvarnishcompat.la \ $(top_builddir)/lib/libvarnishapi/libvarnishapi.la \ - ${CURSES_LIBS} ${RT_LIBS} + ${CURSES_LIBS} ${PTHREAD_LIBS} ${RT_LIBS} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 13:15:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 13:15:20 -0000 Subject: [Varnish] #314: undefined reference to `pthread_self' In-Reply-To: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> References: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> Message-ID: <065.70dd6ade2d3fbf8f09a18de64d7f63f8@projects.linpro.no> #314: undefined reference to `pthread_self' ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by bonetruck2): Sorry, the formatting got hosed. I'll attached them instead. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 13:38:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 13:38:14 -0000 Subject: [Varnish] #315: assertion in STP_LOOKUP Message-ID: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> #315: assertion in STP_LOOKUP ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- {{{ Child (30700) Panic message: Assert error in CNT_Session(), cache_center.c line 1009: Condition(!isnan(w->used)) not true. thread = (cache-worker)sp = 0x1f1a3d68 { fd = 8868, id = 8868, xid = 1813420224, client = 70.50.231.173:61483, step = STP_LOOKUP, handling = HASH, ws = 0x1f1a3dd8 { id = "sess", {s,f,r,e} = {0x1f1a4500,,+1942,(nil),+32768}, }, worker = 0x2ab051159c00 { }, vcl = { srcname = { "/home/artur/wikia-beta.vcl", "Default", }, }, }, }}} no stacktrace sadly -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 14:30:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 14:30:49 -0000 Subject: [Varnish] #311: varnishtest fails at c00005.vtc on ppc64 In-Reply-To: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> References: <052.142aa1d910b66bb782f2118337ce58c9@projects.linpro.no> Message-ID: <061.208d23abe900b4689dfa4cbe06edc1bc@projects.linpro.no> #311: varnishtest fails at c00005.vtc on ppc64 --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in r3171 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 16:49:34 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 16:49:34 -0000 Subject: [Varnish] #315: assertion in STP_LOOKUP In-Reply-To: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> References: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> Message-ID: <058.069f330129ac378637bb39a803762226@projects.linpro.no> #315: assertion in STP_LOOKUP ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: normal | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * milestone: => After 2.0 Comment: This looks patently impossible to me. Either the thread came out of cnt_recv() the only way to get to STP_LOOKUP, but that has an return(0) so it wouldn't break the loop in CNT_Session(). Alternatively it came out of cnt_lookup(), which is indeed possible if we encounter a busy object. But in that case we explicitly set sp->wrk->used to TIM_real() if it is still NAN. All other returns from cnt_lookup() have different STP_*. Until more data arrives, there's not much we can do. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 16:49:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 16:49:56 -0000 Subject: [Varnish] #315: assertion in STP_LOOKUP In-Reply-To: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> References: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> Message-ID: <058.1b6e6b7dd1370d99099422b88c0cfbbd@projects.linpro.no> #315: assertion in STP_LOOKUP ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * priority: normal => lowest -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 16:53:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 16:53:53 -0000 Subject: [Varnish] #314: undefined reference to `pthread_self' In-Reply-To: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> References: <056.0c1fac9bb11b0267c994cfd056e1c7a5@projects.linpro.no> Message-ID: <065.e49da45092e0d15decfbbf698d64a56d@projects.linpro.no> #314: undefined reference to `pthread_self' ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: committed in r3172, thanks. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 16:57:34 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 16:57:34 -0000 Subject: [Varnish] #310: WS_Reserve panic + error In-Reply-To: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> References: <049.b8602d04f753afe2eb5dcabb5e8fbfca@projects.linpro.no> Message-ID: <058.bab9f5e03b91a22d8594ae6752054b46@projects.linpro.no> #310: WS_Reserve panic + error ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * priority: normal => lowest -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 17:36:29 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 17:36:29 -0000 Subject: [Varnish] #309: Varnish freezes if >1k of binary postdata is passed in In-Reply-To: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> References: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> Message-ID: <062.1313f6d4a49c041bd10546c585de1e88@projects.linpro.no> #309: Varnish freezes if >1k of binary postdata is passed in ---------------------+------------------------------------------------------ Reporter: Fry-kun | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => worksforme Comment: The problem here is that you 'pass' a request that has an "Expect:" header. We don't support Expect in pass, only in pipe. I've moved it to the post-2.0 wiki page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 17:37:51 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 17:37:51 -0000 Subject: [Varnish] #315: assertion in STP_LOOKUP In-Reply-To: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> References: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> Message-ID: <058.ab66d4d2189cd2efa30b9ec99e8f4859@projects.linpro.no> #315: assertion in STP_LOOKUP ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by sky): What kind of data out of gdb do you want? And yes, it looks patently impossible to me as well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 17:40:36 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 17:40:36 -0000 Subject: [Varnish] #272: Assert error in vca_acct(), cache_acceptor.c line 173 In-Reply-To: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> References: <056.c3889ac23acaa8d0a7f086436ba34bf6@projects.linpro.no> Message-ID: <065.33e46bcc9804a009d0570311ca2a850a@projects.linpro.no> #272: Assert error in vca_acct(), cache_acceptor.c line 173 ------------------------+--------------------------------------------------- Reporter: bonetruck2 | Owner: phk Type: defect | Status: reopened Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: 1.1.2 Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * priority: normal => lowest -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 18:13:02 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 18:13:02 -0000 Subject: [Varnish] #306: Throwing 503 Service Unavailable despite healthy backend in director In-Reply-To: <052.d8162ce5179a2e131a2a157f640bdab8@projects.linpro.no> References: <052.d8162ce5179a2e131a2a157f640bdab8@projects.linpro.no> Message-ID: <061.2bffab50bfc7bebb58a888bdbe4977ea@projects.linpro.no> #306: Throwing 503 Service Unavailable despite healthy backend in director -----------------------------+---------------------------------------------- Reporter: sensei | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: backend polling | -----------------------------+---------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Neat bug, an off-by one in the random-director when only one backend is healthy. Fixed in r3174 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 19:27:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 19:27:20 -0000 Subject: [Varnish] #316: varnishtest should mkdtemp or similar for its varnishd testing directory Message-ID: <052.7d2f84eda7603f58d11187dea6a0be3d@projects.linpro.no> #316: varnishtest should mkdtemp or similar for its varnishd testing directory --------------------+------------------------------------------------------- Reporter: ingvar | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- If one builds varnish first as root, breaks it while running 'make check', and then build and run make check as a non-privileged user, varnishtest dies on something like this: {{{ Error: (-sfile) "." mkstemp(./varnish.UQTZnP) failed (Permission denied) }}} This is because it uses the same temporary catalog for testing, that is, in my builds, {{{ /tmp/__v1 }}} which is owned by root after the first run. The correct fix would be to use mkdtemp or similar in addition to mkstemp Ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 21:52:54 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 21:52:54 -0000 Subject: [Varnish] #316: varnishtest should mkdtemp or similar for its varnishd testing directory In-Reply-To: <052.7d2f84eda7603f58d11187dea6a0be3d@projects.linpro.no> References: <052.7d2f84eda7603f58d11187dea6a0be3d@projects.linpro.no> Message-ID: <061.6a1f7dae1486ae565d72b5740bffb281@projects.linpro.no> #316: varnishtest should mkdtemp or similar for its varnishd testing directory ----------------------+----------------------------------------------------- Reporter: ingvar | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * owner: des => phk * priority: normal => lowest * component: build => varnishd * milestone: => After 2.0 Comment: First off, /tmp/__v1 is as you probably guessed synthesized from the varnish instance name in the test file. Second, yes, varnishtest should probably hide all its gunk in a temporary subdir, but if you do that, you make any core dumps much harder to retrieve. Third, as I've said repeatedly, I don't think varnishtest is ready for the kind of limelight you are putting it into. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 8 21:53:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 08 Sep 2008 21:53:37 -0000 Subject: [Varnish] #316: varnishtest should mkdtemp or similar for its varnishd testing directory In-Reply-To: <052.7d2f84eda7603f58d11187dea6a0be3d@projects.linpro.no> References: <052.7d2f84eda7603f58d11187dea6a0be3d@projects.linpro.no> Message-ID: <061.070923f3ae3e2223af6de1c363a3be02@projects.linpro.no> #316: varnishtest should mkdtemp or similar for its varnishd testing directory -------------------------+-------------------------------------------------- Reporter: ingvar | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishtest | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * component: varnishd => varnishtest -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 9 07:41:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 09 Sep 2008 07:41:43 -0000 Subject: [Varnish] #254: Condition(oe2->timer_when >= oe->timer_when) not true In-Reply-To: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no> References: <049.1b2e89df017e6914fbbd31b7d1d157b1@projects.linpro.no> Message-ID: <058.352d15628d544b4baafc44a96f640c01@projects.linpro.no> #254: Condition(oe2->timer_when >= oe->timer_when) not true --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: reopened => closed * resolution: => fixed Comment: Closing, since the submitter is no longer able to reproduce this (and it occured fairly frequently before). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 9 08:44:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 09 Sep 2008 08:44:47 -0000 Subject: [Varnish] #55: varnish stops responding with apache keepalive On In-Reply-To: <049.210f15126f587d48d25888bbf845f087@projects.linpro.no> References: <049.210f15126f587d48d25888bbf845f087@projects.linpro.no> Message-ID: <058.a151e0dadc129c73146169cb73f6ce4b@projects.linpro.no> #55: varnish stops responding with apache keepalive On -----------------------+---------------------------------------------------- Reporter: ced | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: invalid Keywords: Keepalive | -----------------------+---------------------------------------------------- Changes (by phk): * status: assigned => closed * resolution: => invalid Comment: Timing this one out due to lack of response. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 9 08:45:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 09 Sep 2008 08:45:12 -0000 Subject: [Varnish] #61: Varnish -> Apache httpd mod_rewrite : 7 seconds delay In-Reply-To: <052.21ea811fe428f87847d7c614e5b9609c@projects.linpro.no> References: <052.21ea811fe428f87847d7c614e5b9609c@projects.linpro.no> Message-ID: <061.f281a9eb3f735512def3475a4808c367@projects.linpro.no> #61: Varnish -> Apache httpd mod_rewrite : 7 seconds delay -------------------------+-------------------------------------------------- Reporter: edward | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: major | Resolution: Keywords: | -------------------------+-------------------------------------------------- Comment (by phk): Timed out due to lack of response. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 9 08:45:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 09 Sep 2008 08:45:25 -0000 Subject: [Varnish] #61: Varnish -> Apache httpd mod_rewrite : 7 seconds delay In-Reply-To: <052.21ea811fe428f87847d7c614e5b9609c@projects.linpro.no> References: <052.21ea811fe428f87847d7c614e5b9609c@projects.linpro.no> Message-ID: <061.e1182f6065c8ae5d7b328bea808829e9@projects.linpro.no> #61: Varnish -> Apache httpd mod_rewrite : 7 seconds delay -------------------------+-------------------------------------------------- Reporter: edward | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: Severity: major | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 9 08:50:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 09 Sep 2008 08:50:43 -0000 Subject: [Varnish] #302: Varnishstat: % of caching: Bytes actually sent VS bytes sent with no cache In-Reply-To: <054.e44e7565fe29a1bc40a93668492c2413@projects.linpro.no> References: <054.e44e7565fe29a1bc40a93668492c2413@projects.linpro.no> Message-ID: <063.3319d0e6fc1e5cf6ab5857708489169d@projects.linpro.no> #302: Varnishstat: % of caching: Bytes actually sent VS bytes sent with no cache -------------------------+-------------------------------------------------- Reporter: The_ZoRo | Owner: phk Type: enhancement | Status: closed Priority: low | Milestone: After 2.0 Component: varnishstat | Version: Severity: normal | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: The idea is not without merit, but the varnishstat window is already too tall for many screens, so I think I will sit this one over. I think one of the post-2.0 activities should be to go over our reporting tools (v-hist, v-stat, v-log & v-ncsa) they are a bit primitive still. A Perl binding for the stats and shmlog is also talked about. I'm closing this and moving it to the post-2.0 list. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 9 08:51:43 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 09 Sep 2008 08:51:43 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> References: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> Message-ID: <065.266bbcad206c285ced43b20304d46fa3@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 1.1.2 Severity: major | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by phk): Sorry, vacation and other business distracted me. Can you give me an update on the situation with this ticket ? Also, I forgot to ask earlier: How large objects does your varnish serve ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 9 08:52:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 09 Sep 2008 08:52:16 -0000 Subject: [Varnish] #204: Handling of HTTP headers In-Reply-To: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no> References: <049.5c2d5cb25689ca35813ab8bcfb5bb74e@projects.linpro.no> Message-ID: <058.d1696a035568c4589ff9be17cc69abc9@projects.linpro.no> #204: Handling of HTTP headers ---------------------------+------------------------------------------------ Reporter: des | Owner: des Type: enhancement | Status: closed Priority: normal | Milestone: After 2.0 Component: documentation | Version: trunk Severity: normal | Resolution: wontfix Keywords: | ---------------------------+------------------------------------------------ Changes (by phk): * status: assigned => closed * resolution: => wontfix Comment: I'm moving this to the post-2.0 wiki page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 10 02:29:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Sep 2008 02:29:56 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> References: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> Message-ID: <065.fd1ccb7a8d4b8e481d9a2798068f94d4@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 1.1.2 Severity: major | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by chrisrixon): Replying to [comment:17 phk]: > Can you give me an update on the situation with this ticket ? Well we upgraded to 64 bit and that works better as it carries on past the 4G limit. Varnish still uses oodles of VM. > Also, I forgot to ask earlier: How large objects does your varnish serve ? 300 bytes to 100K, static objects and PHP, do you want more info? -- Ticket URL: Varnish The Varnish HTTP Accelerator From erik.jansson at bilddagboken.se Wed Sep 10 08:47:35 2008 From: erik.jansson at bilddagboken.se (Erik Jansson) Date: Wed, 10 Sep 2008 10:47:35 +0200 Subject: Varnish crashing excessivly Message-ID: <48C789A7.60603@bilddagboken.se> We've been having problems with squid for a while, so we started trying varnish in our development environment. Everything has been working out well. But after lots of problems with squid last week we decided to give the 2.0 beta a test drive in the production environment. At first everything seemed to be working out great. Our cache machine is a Dell Poweredge 2950 X5355 @ 2.66GHz with about 16GB's of RAM with 5 76GB SAS-drives. We are running Ubuntu. The server is serving images from the backend storage servers. The image sizes varys from about 10k to 200k. At peak hours we have about 4000 requests per second. I compiled varnish with no options. Used this config file. backend images01 { .host = "x.x.x.x"; .port = "80"; } backend images02 { .host = "x.x.x.x"; .port = "80"; } backend lighty { .host = "x.x.x.x"; .port = "80"; } sub vcl_recv { set req.grace = 30s; if (req.request != "GET") { error 507 "Method not allowed"; } if(req.url ~ "^/((imgs)|(stat)|(b))/") { set req.backend = lighty; lookup; } else if (req.url ~ "^/(([0-9]{1,2}/)|(avs))(.*)\.jpg$" ){ if(req.url ~ "^/(([0-9]{1})|([1]{1}[0-9]{1})|([2]{1}[0-8]{1})|(avs))/") { set req.backend = images01; } else if (req.url ~ "^/(([2]{1}[9]{1})|([3]{1}[0-9]{1})|([4]{1}[0-2]{1}))/") { set req.backend = images02; } else { error 508 "Storage not found"; } } else { error 404 "Not Found"; } if (req.http.host ~ "^xy.com$") { set req.http.host = "x.se"; lookup; } else { set req.http.host = "x.se"; if(req.http.Cookie ~ "viewer=ok") { lookup; } else { error 506 "Please visit x.se to view this image"; } } } sub vcl_fetch { set req.grace = 30s; if (!obj.cacheable) { pass; } if (obj.http.Set-Cookie) { pass; } set obj.prefetch = -30s; deliver; } I Started varnish with the following options: ulimit -n 500000 /usr/local/sbin/varnishd -a x.x.x.x:80 \ -f /usr/local/etc/varnish/raptor.vcl \ -T 127.0.0.1:2000 \ -s file,/mnt/cache1/varnish_storage1.bin,80% \ -s file,/mnt/cache2/varnish_storage2.bin,80% \ -s file,/mnt/cache3/varnish_storage3.bin,80% \ -s file,/mnt/cache4/varnish_storage4.bin,80% \ -s file,/mnt/cache5/varnish_storage5.bin,80% \ -p thread_pool_max=4000 \ -p listen_depth=4096 \ -p lru_interval=3600 \ -h classic,800011 \ -t 600 Then we ran in to problems, when watching thru varnishstat the server seemed to stop every now and then (every ~30 seconds). We soon established that it had to do with disk writes hogging up all resources. We've tried tweaking some of the /proc/vm-variables but with no luck so far. Problem #2 is that varnish segfaults every now and then, sometimes many times in a short period, but sometimes it runs for a couple of days without problems. The only lead i have on this is [105474.200474] varnishd[24170]: segfault at 00000000000004a0 rip 000000000041ced0 rsp 00002aef65046af8 error 4 which i got from dmesg We switched over to -s malloc,300G and formatted the disks to swap, and added them with the same priority It ran pretty well for a while, but then the segfaults began again. And when it didn't segfault it hogged up sys %. But the VM-hangs were gone. I tried running with -d -d but didn't get any info about the sys % hogging. The symptom was a pretty unresponsive cache-server during high loads. I am aware that this is probably not even close to all the information you need, I need your help to collect more data about my problems. I would really like to replace squid as soon as possible. From varnish-bugs at projects.linpro.no Wed Sep 10 14:01:20 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Sep 2008 14:01:20 -0000 Subject: [Varnish] #315: assertion in STP_LOOKUP In-Reply-To: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> References: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> Message-ID: <058.0339109356cf87fa8796f2da02c923d4@projects.linpro.no> #315: assertion in STP_LOOKUP ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by sky): {{{ Child (28235) Panic message: Assert error in cnt_fetch(), cache_center.c line 437: Condition(!isnan(sp->wrk->used)) not true. thread = (cache-worker)sp = 0xc649138 { fd = 17, id = 17, xid = 1553094606, client = 203.177.74.135:56313, step = STP_FETCH, handling = PASS, err_code = 200, err_reason = (null), ws = 0xc6491a8 { id = "sess", {s,f,r,e} = {0xc6498d0,,+1309,(nil),+32768}, }, worker = 0x2ab063a1fc00 { }, vcl = { srcname = { "/home/artur/wikia-beta.vcl", "Default", }, }, obj = 0x2aaab1cec000 { refcnt = 1, xid = 1553094606, ws = 0x2aaab1cec028 { id = "obj", {s,f,r,e} = {0x2aaab1cec350,,+377,(nil),+31920}, }, http = { ws = 0x2aaab1cec028 { id = "obj", {s,f,r,e} = {0x2aaab1cec350,,+377,(nil),+31920}, }, hd = { "Date: Wed, 10 Sep 2008 14:00:13 GMT", "Server: Apache", "X-Powered-By: PHP/5.2.6", "Expires: Thu, 01 Jan 1970 00:00:01 GMT", "Cache-Control: s-maxage=0, must-revalidate, max-age=0", "Content-Encoding: gzip", "Vary: Accept-Encoding", "X-Vary-Options: Accept-Encoding;list-contains=gzip", "Content-Type: application/json; charset=utf-8", "Content-Length: 936", "X-Cacheable: NO:Not-Cacheable", }, }, len = 936, store = { 936 { 1f 8b 08 00 00 00 00 00 00 03 9d 56 6d 8f e2 36 |...........Vm..6| 10 fe 2b 6e aa ab da 9e 42 5e 00 dd 6e 36 8d d4 |..+n....B^..n6..| 5e 39 09 a9 3d ad 8e aa 9f 2c 21 27 19 88 b5 8e |^9..=....,!'....| ed b3 9d 85 ed 69 ff 7b c7 81 40 a0 b4 3a 15 21 |.....i.{.. at ..:.!| [872 more] }, }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 10 20:07:19 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Sep 2008 20:07:19 -0000 Subject: [Varnish] #273: running out of virtual memory on 32 bit server In-Reply-To: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> References: <056.39825030aa405e311ecaa7bd0075720a@projects.linpro.no> Message-ID: <065.fe0aeeed32247242574e3b98cb1f0c5f@projects.linpro.no> #273: running out of virtual memory on 32 bit server ------------------------+--------------------------------------------------- Reporter: chrisrixon | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 1.1.2 Severity: major | Resolution: worksforme Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => worksforme Comment: Ok, so I think we can conclude that you simply were running into the 32bit limit. Varnish does use oodles of VM, it's built to take advantage of the Virtual Memory system in the computer to the full extent possible, so that is not a problem indication. I'll close this ticket then. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 10 20:08:11 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 10 Sep 2008 20:08:11 -0000 Subject: [Varnish] #315: assertion in STP_LOOKUP In-Reply-To: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> References: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> Message-ID: <058.2cbdaee5ec60ad097818daba4770d00a@projects.linpro.no> #315: assertion in STP_LOOKUP ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I think I have spotted a leak in a micro-optimization. I have a tentative patch you can test here: http://phk.freebsd.dk/patch/t315.patch -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 11 21:27:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 11 Sep 2008 21:27:47 -0000 Subject: [Varnish] #317: Assert error in cnt_lookup(), cache_center.c line 618: Message-ID: <049.2001191c536f6d5ddeac8e5d28afc629@projects.linpro.no> #317: Assert error in cnt_lookup(), cache_center.c line 618: --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- This happened running r3177 + one line hot fix (can't find the line I added and my irc log isn't that old) When I recompiled recompiled r3177 + t315.patch I haen't seen this since {{{ Child (31147) died signal=6 Child (31147) Panic message: Assert error in cnt_lookup(), cache_center.c line 618: Condition(sp->objhead != NULL) not true. thread = (cache-worker)sp = 0x19a7a358 { fd = 2454, id = 2454, xid = 660090216, client = 70.221.207.13:50371, step = STP_LOOKUP, handling = HASH, err_code = 200, err_reason = (null), ws = 0x19a7a3c8 { id = "sess", {s,f,r,e} = {0x19a7aaf0,,+1323,(nil),+32768}, }, worker = 0x2ab0247bac00 { }, vcl = { srcname = { "/home/artur/wikia-beta.vcl", "Default", }, }, }, }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 08:51:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 08:51:35 -0000 Subject: [Varnish] #315: assertion in STP_LOOKUP In-Reply-To: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> References: <049.3ecd4246b76bc9c3d34f02cead80ac9e@projects.linpro.no> Message-ID: <058.571319e0779bc291a7b94a7fe61d886c@projects.linpro.no> #315: assertion in STP_LOOKUP ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: I belive r3182 fixes this. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:00:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:00:22 -0000 Subject: [Varnish] #295: Varnishd using all available memory, even using limited malloc In-Reply-To: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> References: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> Message-ID: <057.fac2c3d496856fab388262c10df38386@projects.linpro.no> #295: Varnishd using all available memory, even using limited malloc -------------------------------------+-------------------------------------- Reporter: ay | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: major | Resolution: Keywords: leak memory malloc swap | -------------------------------------+-------------------------------------- Old description: > I need some help to understand this > > I have a 64bit server with 32GB of RAM and 60GB SWAP > > And varnish is running with these parameters > > /usr/sbin/varnishd -a :80 -f /etc/varnish/nettby.vcl -T 127.0.0.1:82 -t > 120 -u varnish -g varnish -p thread_pool_add_delay 100 -p > thread_pool_timeout 600 -p client_http11 on -p lru_interval 3600 -s > malloc,30G -P /var/run/varnish.pid > > malloc'ed 30G of memory.. So in theory I should not even need swap. > > But > > [root at sol ~]# free -m > total used free shared buffers cached > Mem: 32242 31735 507 0 0 92 > -/+ buffers/cache: 31642 600 > Swap: 59871 51322 8549 > > The machine is using 51GB of swap and is swapping in pages frequently > > [root at sol ~]# vmstat 1 > procs -----------memory---------- ---swap-- -----io---- --system-- > -----cpu------ > r b swpd free buff cache si so bi bo in cs us sy > id wa st > 0 0 52549748 446992 780 96284 29 11 48 157 1 1 4 > 2 92 1 0 > 0 0 52549708 530360 780 96348 280 0 280 0 9654 6935 4 > 8 87 1 0 > 0 0 52549708 528160 780 96420 0 0 0 0 6785 7560 2 > 2 96 0 0 > 0 0 52549664 526668 780 96316 316 0 316 0 6570 7350 2 > 2 95 1 0 > 0 0 52549648 524932 780 96396 104 0 104 0 6300 7456 2 > 1 96 0 0 > 0 0 52549644 523372 780 96400 28 0 28 0 6013 7099 2 > 2 96 0 0 > 0 0 52549640 521884 788 96424 28 0 28 28 5649 7343 2 > 2 96 0 0 > > > [root at sol ~]# varnishstat -1 > client_conn 2089633996 362.23 Client connections accepted > client_req 8345199749 1446.62 Client requests received > cache_hit 8289156139 1436.90 Cache hits > cache_hitpass 1610 0.00 Cache hits for pass > cache_miss 53623537 9.30 Cache misses > backend_conn 53621117 9.30 Backend connections success > backend_fail 4031 0.00 Backend connections failures > backend_reuse 0 0.00 Backend connections reuses > backend_recycle 0 0.00 Backend connections recycles > backend_unused 0 0.00 Backend connections unused > n_srcaddr 7689 . N struct srcaddr > n_srcaddr_act 4164 . N active struct srcaddr > n_sess_mem 59601 . N struct sess_mem > n_sess 64719 . N struct sess > n_object 2025596 . N struct object > n_objecthead 2025576 . N struct objecthead > n_smf 0 . N struct smf > n_smf_frag 0 . N small free smf > n_smf_large 0 . N large free smf > n_vbe_conn 106 . N struct vbe_conn > n_bereq 96 . N struct bereq > n_wrk 78 . N worker threads > n_wrk_create 15968 0.00 N worker threads created > n_wrk_failed 0 0.00 N worker threads not created > n_wrk_max 191919689 33.27 N worker threads limited > n_wrk_queue 0 0.00 N queued work requests > n_wrk_overflow 210128619 36.43 N overflowed work requests > n_wrk_drop 31202342 5.41 N dropped work requests > n_backend 1 . N backends > n_expired 31600718 . N expired objects > n_lru_nuked 20008124 . N LRU nuked objects > n_lru_saved 0 . N LRU saved objects > n_lru_moved 779599235 . N LRU moved objects > n_deathrow 0 . N objects on deathrow > losthdr 196 0.00 HTTP header overflows > n_objsendfile 0 0.00 Objects sent with sendfile > n_objwrite 6674989721 1157.09 Objects sent with write > n_objoverflow 0 0.00 Objects overflowing workspace > s_sess 2073648637 359.46 Total Sessions > s_req 8345234372 1446.62 Total Requests > s_pipe 0 0.00 Total pipe > s_pass 0 0.00 Total pass > s_fetch 53620083 9.29 Total fetch > s_hdrbytes 2924438007698 506943.34 Total header bytes > s_bodybytes 13839780950697 2399088.22 Total body bytes > sess_closed 54123498 9.38 Session Closed > sess_pipeline 0 0.00 Session Pipeline > sess_readahead 42322579 7.34 Session Read Ahead > sess_herd 8270331676 1433.64 Session herd > shm_records 347828089203 60295.05 SHM records > shm_writes 14631506809 2536.33 SHM writes > shm_flushes 908314 0.16 SHM flushes due to overflow > shm_cont 14245861 2.47 SHM MTX contention > sm_nreq 0 0.00 allocator requests > sm_nobj 0 . outstanding allocations > sm_balloc 0 . bytes allocated > sm_bfree 0 . bytes free > sma_nreq 127269201 22.06 SMA allocator requests > sma_nobj 4019319 . SMA outstanding allocations > sma_nbytes 32212251961 . SMA outstanding bytes > sma_balloc 891934739829 . SMA bytes allocated > sma_bfree 859722487868 . SMA bytes free > backend_req 53621117 9.30 Backend requests made New description: I need some help to understand this I have a 64bit server with 32GB of RAM and 60GB SWAP And varnish is running with these parameters {{{ /usr/sbin/varnishd -a :80 -f /etc/varnish/nettby.vcl -T 127.0.0.1:82 -t 120 -u varnish -g varnish -p thread_pool_add_delay 100 -p thread_pool_timeout 600 -p client_http11 on -p lru_interval 3600 -s malloc,30G -P /var/run/varnish.pid malloc'ed 30G of memory.. So in theory I should not even need swap. But [root at sol ~]# free -m total used free shared buffers cached Mem: 32242 31735 507 0 0 92 -/+ buffers/cache: 31642 600 Swap: 59871 51322 8549 The machine is using 51GB of swap and is swapping in pages frequently [root at sol ~]# vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 52549748 446992 780 96284 29 11 48 157 1 1 4 2 92 1 0 0 0 52549708 530360 780 96348 280 0 280 0 9654 6935 4 8 87 1 0 0 0 52549708 528160 780 96420 0 0 0 0 6785 7560 2 2 96 0 0 0 0 52549664 526668 780 96316 316 0 316 0 6570 7350 2 2 95 1 0 0 0 52549648 524932 780 96396 104 0 104 0 6300 7456 2 1 96 0 0 0 0 52549644 523372 780 96400 28 0 28 0 6013 7099 2 2 96 0 0 0 0 52549640 521884 788 96424 28 0 28 28 5649 7343 2 2 96 0 0 [root at sol ~]# varnishstat -1 client_conn 2089633996 362.23 Client connections accepted client_req 8345199749 1446.62 Client requests received cache_hit 8289156139 1436.90 Cache hits cache_hitpass 1610 0.00 Cache hits for pass cache_miss 53623537 9.30 Cache misses backend_conn 53621117 9.30 Backend connections success backend_fail 4031 0.00 Backend connections failures backend_reuse 0 0.00 Backend connections reuses backend_recycle 0 0.00 Backend connections recycles backend_unused 0 0.00 Backend connections unused n_srcaddr 7689 . N struct srcaddr n_srcaddr_act 4164 . N active struct srcaddr n_sess_mem 59601 . N struct sess_mem n_sess 64719 . N struct sess n_object 2025596 . N struct object n_objecthead 2025576 . N struct objecthead n_smf 0 . N struct smf n_smf_frag 0 . N small free smf n_smf_large 0 . N large free smf n_vbe_conn 106 . N struct vbe_conn n_bereq 96 . N struct bereq n_wrk 78 . N worker threads n_wrk_create 15968 0.00 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 191919689 33.27 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 210128619 36.43 N overflowed work requests n_wrk_drop 31202342 5.41 N dropped work requests n_backend 1 . N backends n_expired 31600718 . N expired objects n_lru_nuked 20008124 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 779599235 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 196 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 6674989721 1157.09 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 2073648637 359.46 Total Sessions s_req 8345234372 1446.62 Total Requests s_pipe 0 0.00 Total pipe s_pass 0 0.00 Total pass s_fetch 53620083 9.29 Total fetch s_hdrbytes 2924438007698 506943.34 Total header bytes s_bodybytes 13839780950697 2399088.22 Total body bytes sess_closed 54123498 9.38 Session Closed sess_pipeline 0 0.00 Session Pipeline sess_readahead 42322579 7.34 Session Read Ahead sess_herd 8270331676 1433.64 Session herd shm_records 347828089203 60295.05 SHM records shm_writes 14631506809 2536.33 SHM writes shm_flushes 908314 0.16 SHM flushes due to overflow shm_cont 14245861 2.47 SHM MTX contention sm_nreq 0 0.00 allocator requests sm_nobj 0 . outstanding allocations sm_balloc 0 . bytes allocated sm_bfree 0 . bytes free sma_nreq 127269201 22.06 SMA allocator requests sma_nobj 4019319 . SMA outstanding allocations sma_nbytes 32212251961 . SMA outstanding bytes sma_balloc 891934739829 . SMA bytes allocated sma_bfree 859722487868 . SMA bytes free backend_req 53621117 9.30 Backend requests made }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:07:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:07:37 -0000 Subject: [Varnish] #295: Varnishd using all available memory, even using limited malloc In-Reply-To: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> References: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> Message-ID: <057.9e0bdc50cf2ee0b840f102ffccfeb893@projects.linpro.no> #295: Varnishd using all available memory, even using limited malloc -------------------------------------+-------------------------------------- Reporter: ay | Owner: des Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: major | Resolution: Keywords: leak memory malloc swap | -------------------------------------+-------------------------------------- Comment (by phk): It's not quite clear if this is varnish or platform malloc. It would be valuable if you could try to use the JEMALLOC allocator as a test: http://www.canonware.com/~ttt/2008/08/stand-alone-jemalloc-for-linux.html And see if that has different behaviour. You may also see better performance, jemalloc is king of the hill in malloc implementations right now as far as I know. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:10:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:10:21 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.e9b9e1b76a018ccdf59832bad0d0e225@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by phk): Can you try to increase the "cli_timeout" parameter to something like 10-20 seconds, to see if the hang is permanent or temporary ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:13:02 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:13:02 -0000 Subject: [Varnish] #217: varnishtop freeze In-Reply-To: <049.a5bcd9b08e2b26a91152e804621bfcd7@projects.linpro.no> References: <049.a5bcd9b08e2b26a91152e804621bfcd7@projects.linpro.no> Message-ID: <058.c8d3da05269b6f0b14acb6dabf6d7788@projects.linpro.no> #217: varnishtop freeze ------------------------+--------------------------------------------------- Reporter: akv | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Lacking news, I will close this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:13:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:13:38 -0000 Subject: [Varnish] #280: Workspace overflows give confusing error messaqe In-Reply-To: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> References: <053.40d95db607cb35c52fe08f22be199eb9@projects.linpro.no> Message-ID: <062.e2da47eb3674145b4c04d305f0b9592d@projects.linpro.no> #280: Workspace overflows give confusing error messaqe ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * priority: normal => lowest -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:14:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:14:39 -0000 Subject: [Varnish] #284: Child [] Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476 In-Reply-To: <048.d9cc14005f21c6485d454c73891ba1cb@projects.linpro.no> References: <048.d9cc14005f21c6485d454c73891ba1cb@projects.linpro.no> Message-ID: <057.bcb49ef66204c8425540794166e632b2@projects.linpro.no> #284: Child [] Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476 ----------------------+----------------------------------------------------- Reporter: wg | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Old description: > Built from trunk r2999. Many errors logged as below. Can provide other > messages if required, but they don't seem to provide any further > information. I'm unable to reproduce, as I've only noticed the errors > passively. > {{ > Jul 27 08:52:15 soyuz varnishd[60663]: Child (41081) Panic message: > Assert error in VRT_r_server_ip(), cache_vrt.c line 476: > Condition((getsockname(sp->fd, sp->mysockaddr, &sp->mysockaddrlen)) == 0) > not true. errno = 54 (Connection reset by peer) > thread = (cache-worker) > sp = 0x823a004 { fd = 21, id = 21, xid = 263428262, > client = 65.55.110.26:62815, > step = STP_RECV, > ws = 0x823a04c { > id = "sess", {s,f,r,e} = {0x823a4cc,,+371,0x0,+8192}, }, > worker = 0xbeff4cf0 { }, > vcl = { srcname = { > "/usr/local/etc/varnish/soyuz+virtual.vcl", > "Default", > }, > }, > }, > Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Child starts > Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Closed fds: 4 5 > 6 7 13 14 16 17 > Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Ready > Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said managed to mmap > 2147467264 bytes of 2147467264 > Jul 27 08:52:15 soyuz varnishd[60663]: child (49962) Started > }}} New description: Built from trunk r2999. Many errors logged as below. Can provide other messages if required, but they don't seem to provide any further information. I'm unable to reproduce, as I've only noticed the errors passively. {{{ Jul 27 08:52:15 soyuz varnishd[60663]: Child (41081) Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476: Condition((getsockname(sp->fd, sp->mysockaddr, &sp->mysockaddrlen)) == 0) not true. errno = 54 (Connection reset by peer) thread = (cache-worker) sp = 0x823a004 { fd = 21, id = 21, xid = 263428262, client = 65.55.110.26:62815, step = STP_RECV, ws = 0x823a04c { id = "sess", {s,f,r,e} = {0x823a4cc,,+371,0x0,+8192}, }, worker = 0xbeff4cf0 { }, vcl = { srcname = { "/usr/local/etc/varnish/soyuz+virtual.vcl", "Default", }, }, }, Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Child starts Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Closed fds: 4 5 6 7 13 14 16 17 Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said Ready Jul 27 08:52:15 soyuz varnishd[60663]: Child (49962) said managed to mmap 2147467264 bytes of 2147467264 Jul 27 08:52:15 soyuz varnishd[60663]: child (49962) Started }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:15:27 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:15:27 -0000 Subject: [Varnish] #279: varnishlog init file does not work In-Reply-To: <053.b4a00ef4b4838543b6472ad25ed4610c@projects.linpro.no> References: <053.b4a00ef4b4838543b6472ad25ed4610c@projects.linpro.no> Message-ID: <062.479f447280e45fcd03c40700652d87cf@projects.linpro.no> #279: varnishlog init file does not work -----------------------+---------------------------------------------------- Reporter: marlier | Owner: ingvar Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: trunk Severity: normal | Resolution: Keywords: | -----------------------+---------------------------------------------------- Changes (by tfheen): * owner: => ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:15:34 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:15:34 -0000 Subject: [Varnish] #223: fixed redhat varnishlog init script and added one for varnishncsa In-Reply-To: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> References: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> Message-ID: <061.a2ebd22edcbb4030f9bcfca5b4aea7cb@projects.linpro.no> #223: fixed redhat varnishlog init script and added one for varnishncsa -------------------------------------------+-------------------------------- Reporter: hillct | Owner: ingvar Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: packaging | Version: trunk Severity: normal | Resolution: Keywords: varnishlog varnishncsa redhat | -------------------------------------------+-------------------------------- Changes (by tfheen): * owner: des => ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 09:16:54 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 09:16:54 -0000 Subject: [Varnish] #190: VCL Sample In-Reply-To: <057.c1af45dfcb09cdebdbb846ab6cba109a@projects.linpro.no> References: <057.c1af45dfcb09cdebdbb846ab6cba109a@projects.linpro.no> Message-ID: <066.72042cfc25f5a0d029d3f9c4598e01da@projects.linpro.no> #190: VCL Sample ---------------------------+------------------------------------------------ Reporter: michael.lee | Owner: tfheen Type: documentation | Status: new Priority: normal | Milestone: Component: documentation | Version: 1.1.1 Severity: normal | Resolution: Keywords: | ---------------------------+------------------------------------------------ Changes (by tfheen): * owner: petter => tfheen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 12 11:09:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 11:09:14 -0000 Subject: [Varnish] #223: fixed redhat varnishlog init script and added one for varnishncsa In-Reply-To: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> References: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> Message-ID: <061.fa794d8b20654063b7be69a25349cb4a@projects.linpro.no> #223: fixed redhat varnishlog init script and added one for varnishncsa -------------------------------------------+-------------------------------- Reporter: hillct | Owner: ingvar Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: packaging | Version: trunk Severity: normal | Resolution: Keywords: varnishlog varnishncsa redhat | -------------------------------------------+-------------------------------- Comment (by ingvar): An init script for varnishncsa is nice, thanks. I'll fix it up to lsb/fedora9 standard and aply it, thank you. As for the "bug", just add a check for %dist="fc8" or something, no need to manually patch the init scripts. I'll add a fix for that in trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From tfheen at linpro.no Fri Sep 12 11:45:23 2008 From: tfheen at linpro.no (Tollef Fog Heen) Date: Fri, 12 Sep 2008 13:45:23 +0200 Subject: Varnish crashing excessivly In-Reply-To: <48C789A7.60603@bilddagboken.se> (Erik Jansson's message of "Wed, 10 Sep 2008 10:47:35 +0200") References: <48C789A7.60603@bilddagboken.se> Message-ID: <87prn9fuzw.fsf@qurzaw.linpro.no> ]] Erik Jansson | Our cache machine is a Dell Poweredge 2950 X5355 @ 2.66GHz with about | 16GB's of RAM with 5 76GB SAS-drives. We are running Ubuntu. The server | is serving images from the backend storage servers. The image sizes | varys from about 10k to 200k. At peak hours we have about 4000 requests | per second. Which Ubuntu version are you using? [...] | Problem #2 is that varnish segfaults every now and then, sometimes many | times in a short period, but sometimes it runs for a couple of days | without problems. The only lead i have on this is | [105474.200474] varnishd[24170]: segfault at 00000000000004a0 rip | 000000000041ced0 rsp 00002aef65046af8 error 4 | which i got from dmesg We have fixed some bugs which were triggered in high-volume environments; could you see if the problem goes away by updating to current trunk? [...] | I am aware that this is probably not even close to all the information | you need, I need your help to collect more data about my problems. I | would really like to replace squid as soon as possible. A backtrace from when it crashes would be useful; ulimit -c unlimited should help with that, but note that the core file will be quite large, so you might want to try updating first. Oh, and please file a ticket about this so we're tracking this properly. :-) -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From varnish-bugs at projects.linpro.no Fri Sep 12 11:57:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 12 Sep 2008 11:57:04 -0000 Subject: [Varnish] #223: fixed redhat varnishlog init script and added one for varnishncsa In-Reply-To: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> References: <052.0a72877af7628ee3eb86ab4b4655aad2@projects.linpro.no> Message-ID: <061.261bc787a781379ef361f4bc1d6bd084@projects.linpro.no> #223: fixed redhat varnishlog init script and added one for varnishncsa -------------------------------------------+-------------------------------- Reporter: hillct | Owner: ingvar Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: packaging | Version: trunk Severity: normal | Resolution: fixed Keywords: varnishlog varnishncsa redhat | -------------------------------------------+-------------------------------- Changes (by ingvar): * status: new => closed * resolution: => fixed Comment: Fixed in revision 3184 in trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 15 03:01:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Sep 2008 03:01:55 -0000 Subject: [Varnish] #318: Bug when 302 redirect used on ESI page Message-ID: <053.9170b917a29ae357e742b547056a0600@projects.linpro.no> #318: Bug when 302 redirect used on ESI page ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- When a 302 redirect occurs on a page with ESI varnish panics and no page is returned. Full Config file available if necessary. {{{ elseif(req.url ~ "/login.php") { esi; /* Do ESI processing */ pass; } }}} (in this case login.php redirects with 302 if user is already logged in) (ESI is used if user is not logged in) The same error occurs with a 301 redirect too. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 15 11:17:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Sep 2008 11:17:57 -0000 Subject: [Varnish] #295: Varnishd using all available memory, even using limited malloc In-Reply-To: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> References: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> Message-ID: <057.4c92fc187b4e1094a9081227de14758a@projects.linpro.no> #295: Varnishd using all available memory, even using limited malloc -------------------------------------+-------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: major | Resolution: Keywords: leak memory malloc swap | -------------------------------------+-------------------------------------- Changes (by tfheen): * owner: des => phk -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 15 11:20:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Sep 2008 11:20:14 -0000 Subject: [Varnish] #278: Backend connection does not timeout In-Reply-To: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> References: <048.5aafc667ca300114a7a930aa0dfa6320@projects.linpro.no> Message-ID: <057.8aa5fd273bd56eaa31d7cb2169e8c55f@projects.linpro.no> #278: Backend connection does not timeout ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: PURGE | ----------------------+----------------------------------------------------- Changes (by phk): * priority: normal => lowest * milestone: Varnish 2.0 code complete => After 2.0 Comment: We will not get to this one before 2.0 release. Presently we have only a connection timeout for the backends, once we have a connection, we expect them to work or break, not just linger. A more paranoid attitude is probably warranted. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 15 11:21:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Sep 2008 11:21:41 -0000 Subject: [Varnish] #268: Make 304 and Last-Modified work with ESI In-Reply-To: <049.562ba092d4a09f6f293514999f686752@projects.linpro.no> References: <049.562ba092d4a09f6f293514999f686752@projects.linpro.no> Message-ID: <058.e20e14626e512501a2368dd237d3b123@projects.linpro.no> #268: Make 304 and Last-Modified work with ESI -------------------------+-------------------------------------------------- Reporter: sky | Owner: phk Type: enhancement | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * priority: normal => lowest * milestone: => After 2.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 15 11:24:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Sep 2008 11:24:22 -0000 Subject: [Varnish] #265: Implement nuke option to invalidate all variants of an object In-Reply-To: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> References: <049.c3cf8c01fb7368afd2bc776715d3da78@projects.linpro.no> Message-ID: <058.a2238d72c17cfd2c0599a119fa18e853@projects.linpro.no> #265: Implement nuke option to invalidate all variants of an object -------------------------+-------------------------------------------------- Reporter: sky | Owner: phk Type: enhancement | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * priority: normal => lowest * milestone: => After 2.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 15 11:27:27 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 15 Sep 2008 11:27:27 -0000 Subject: [Varnish] #259: support for revalidating with 304, support for user-reloading In-Reply-To: <050.6d118020109bff8153f1892f0127911c@projects.linpro.no> References: <050.6d118020109bff8153f1892f0127911c@projects.linpro.no> Message-ID: <059.e147a5f61ff0d575ca2c866535ec1066@projects.linpro.no> #259: support for revalidating with 304, support for user-reloading -------------------------+-------------------------------------------------- Reporter: ebik | Owner: phk Type: enhancement | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: worksforme Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I think you can do this already. Look at the squid "PURGE" VCL examples, loose the vcl_miss{} part, insert a "restart" after vcl_hit{} sets the obj.ttl to zero. That should give you the desired behaviour. Sorry about the slow response. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 03:10:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 03:10:39 -0000 Subject: [Varnish] #319: VCL_error_method ,child exited on signal 6 Message-ID: <052.2debb56e1597ebf285a6414c1b99e75b@projects.linpro.no> #319: VCL_error_method ,child exited on signal 6 -------------------------------------------------------------------+-------- Reporter: chenxy | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: VRT_r_req_xid,err_code 403, err_reason Request denied | -------------------------------------------------------------------+-------- os: FreeBSD 7.0-RELEASE (GENERIC) amd64[[BR]] version: trunk R3113 logfile lines: {{{ Sep 15 13:32:11 236-25 kernel: pid 79877 (varnishd), uid 65534: exited on signal 6 (core dumped) Sep 15 13:32:12 236-25 varnishd[72350]: Child (79877) Panic message: Assert error in VRT_r_req_xid(), cache_vrt.c line 483: Condition(snprintf(p, size, "%d", sp->xid) < size) not true. errno = 32 (Broken pipe) thread = (cache-worker)sp = 0x180c20d008 { fd = 1428, id = 1428, xid = 2147519919, client = 222.76.177.239:26384, step = 0xb, handling = 0x0, err_code = 403, err_reason = Request denied., ws = 0x180c20d078 { id = "sess", {s,f,r,e} = {0x180c20d7a0,,+666,0x0,+8192}, }, worker = 0x7fffdeaf6ac0 { }, vcl = { srcname = { "/usr/local/etc/vcl.conf", "Default", }, }, obj = 0x8ca75d000 { refcnt = 1, xid = 2147519919, ws = 0x8ca75d028 { id = "obj", {s,f,r,e} = {0x8ca75d348,,+136,0x0,+7352}, }, http = { ws = 0x8ca75d028 { id = "obj", {s,f,r,e} = {0x8ca75d348,,+136,0x0,+7352}, }, hd = { "Date: Mon, 15 Sep 2008 05:31:22 GMT", "Server: Varnish", "Retry-After: 0" Sep 15 13:32:12 236-25 varnishd[72350]: child (4407) Started Sep 15 13:32:12 236-25 varnishd[72350]: Child (4407) said Closed fds: 7 8 11 12 14 15 Sep 15 13:32:12 236-25 varnishd[72350]: Child (4407) said Child starts Sep 15 13:32:12 236-25 varnishd[72350]: Child (4407) said managed to mmap 17179869184 bytes of 17179869184 Sep 15 13:32:12 236-25 varnishd[72350]: Child (4407) said Ready }}} vcl file: {{{ backend image2 { .host = "10.71.5.248"; .port = "80"; } backend ad4 { .host = "10.71.5.247"; .port = "80"; } sub vcl_hash { set req.hash += req.url; set req.hash += req.http.host; hash; } sub vcl_hit { deliver; } sub vcl_miss { fetch; } sub vcl_recv { if ( req.request != "GET" && req.request != "HEAD" ) { error 403 "Invalid request method."; } elseif ( req.http.host == "image2.xxx.com" || req.http.host ~ ".xxx.com.cn$" ) { set req.backend = image2; } elseif ( req.http.host ~ "^d[0-9].xxx.com$" || req.http.host ~ "^ad[0-9].xxx.com$" || req.http.host ~ "^a[0-9].xxx.com$" || req.http.host == "show.xxx.com") { set req.backend = ad4; } else { error 403 "Request denied."; } if (req.url ~ "\.(gif|png|jpg|js)") { unset req.http.cookie; unset req.http.authenticate; } lookup; } sub vcl_fetch { if ( req.http.host == "image2.xxx.com" || req.http.host ~ ".xxx.com.cn$" ) { set obj.ttl = 86400s; } elseif ( req.http.host ~ "^d[0-9].xxx.com$" || req.http.host ~ "^ad[0-9].xxx.com$" || req.http.host ~ "^a[0-9].xxx.com$" || req.http.host == "show.xxx.com") { set obj.ttl = 300s; } set obj.prefetch = -30s; } sub vcl_deliver { deliver; } sub vcl_timeout { discard; } sub vcl_discard { discard; } }}} gdb: {{{ (gdb) bt #0 0x0000000800d1cfec in thr_kill () from /lib/libc.so.7 #1 0x0000000800da6c5b in abort () from /lib/libc.so.7 #2 0x000000000041b1d8 in pan_ic (func=Variable "func" is not available. ) at cache_panic.c:321 #3 0x0000000000423016 in VRT_r_req_xid (sp=0x180c20d008) at cache_vrt.c:483 #4 0x0000001821402254 in ?? () from ./vcl.FANefPfn.so #5 0x000000000042088b in VCL_error_method (sp=0x180c20d008) at vcl_returns.h:48 #6 0x000000000040f536 in cnt_error (sp=0x180c20d008) at cache_center.c:343 #7 0x000000000040ff68 in CNT_Session (sp=0x180c20d008) at steps.h:43 #8 0x000000000041ce9a in wrk_do_cnt_sess (w=0x7fffdeaf6ac0, priv=Variable "priv" is not available. ) at cache_pool.c:363 #9 0x000000000041bf54 in wrk_thread (priv=0x800f66010) at cache_pool.c:276 #10 0x0000000800aa4a38 in pthread_getprio () from /lib/libthr.so.3 #11 0x00007fffde8f7000 in ?? () Cannot access memory at address 0x7fffdeaf7000 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 04:02:36 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 04:02:36 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.b2c2caa335b3ecebf0e8036e40f1a32f@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): I had changed the parameter. But child exited again with not responding to ping . I feel that is because the swap file synchronization in kernel, I will change scheduling method of kernel and filesystem parameter , I will try again. {{{ param.show 200 1873 ...... cli_timeout 20 [seconds] ping_interval 10 [seconds] ...... }}} but {{{ Sep 15 13:32:12 236-25 kernel: fter: 0" Sep 15 13:32:12 236-25 varnishd[72350]: child (4407) Started Sep 15 13:32:12 236-25 varnishd[72350]: Child (4407) said Closed fds: 7 8 11 12 14 15 Sep 15 13:32:12 236-25 varnishd[72350]: Child (4407) said Child starts Sep 15 13:32:12 236-25 varnishd[72350]: Child (4407) said managed to mmap 17179869184 bytes of 17179869184 Sep 15 13:32:12 236-25 last message repeated 3 times Sep 15 13:32:12 236-25 varnishd[72350]: Child (4407) said Ready Sep 15 17:04:11 236-25 varnishd[72350]: Child (4407) not responding to ping, killing it. Sep 15 17:04:16 236-25 kernel: pid 4407 (varnishd), uid 65534: exited on signal 3 (core dumped) Sep 15 17:04:16 236-25 varnishd[72350]: Child (4407) not responding to ping, killing it. Sep 15 17:04:17 236-25 varnishd[72350]: child (14869) Started Sep 15 17:04:17 236-25 varnishd[72350]: Child (14869) said Closed fds: 7 8 11 12 14 15 Sep 15 17:04:17 236-25 varnishd[72350]: Child (14869) said Child starts Sep 15 17:04:17 236-25 varnishd[72350]: Child (14869) said managed to mmap 17179869184 bytes of 17179869184 Sep 15 17:04:17 236-25 last message repeated 3 times Sep 15 17:04:17 236-25 varnishd[72350]: Child (14869) said Ready }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 09:06:44 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 09:06:44 -0000 Subject: [Varnish] #303: Description length in 2. column in varnishtop is too short In-Reply-To: <054.1517f0c50d06e68d29d27aaef67b8dae@projects.linpro.no> References: <054.1517f0c50d06e68d29d27aaef67b8dae@projects.linpro.no> Message-ID: <063.f5c46c51d731bd8bad942c1948cc88d9@projects.linpro.no> #303: Description length in 2. column in varnishtop is too short ------------------------+--------------------------------------------------- Reporter: The_ZoRo | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishtop | Version: trunk Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This is fixed in commit 3187. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 09:07:58 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 09:07:58 -0000 Subject: [Varnish] #308: Worker threads reported 0 In-Reply-To: <049.5aeeeeb54ccb74dfc40ac59a38ead667@projects.linpro.no> References: <049.5aeeeeb54ccb74dfc40ac59a38ead667@projects.linpro.no> Message-ID: <058.879507866d86328315292c690a4d958d@projects.linpro.no> #308: Worker threads reported 0 --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in commit 3188. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 12:28:48 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 12:28:48 -0000 Subject: [Varnish] #279: varnishlog init file does not work In-Reply-To: <053.b4a00ef4b4838543b6472ad25ed4610c@projects.linpro.no> References: <053.b4a00ef4b4838543b6472ad25ed4610c@projects.linpro.no> Message-ID: <062.5ffa71de0d487a0c0be4ff03b2d3f0f5@projects.linpro.no> #279: varnishlog init file does not work -----------------------+---------------------------------------------------- Reporter: marlier | Owner: ingvar Type: defect | Status: closed Priority: normal | Milestone: Component: packaging | Version: trunk Severity: normal | Resolution: fixed Keywords: | -----------------------+---------------------------------------------------- Changes (by ingvar): * status: new => closed * resolution: => fixed Comment: init script for fedora in use on rhel4. This was fixed in trunk a while ago. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 18:48:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 18:48:01 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.476f829b7e034afc775fe88bf3e34de8@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by phk): The VRT_r_xid() assert was fixed yesterday or so. If you run the gstat(8) program, how much I/O activity do you see ? (normally / when crashing) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 18:49:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 18:49:38 -0000 Subject: [Varnish] #319: VCL_error_method ,child exited on signal 6 In-Reply-To: <052.2debb56e1597ebf285a6414c1b99e75b@projects.linpro.no> References: <052.2debb56e1597ebf285a6414c1b99e75b@projects.linpro.no> Message-ID: <061.775d3c46edff9ea5d2453a5a7104117f@projects.linpro.no> #319: VCL_error_method ,child exited on signal 6 -------------------------------------------------------------------+-------- Reporter: chenxy | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: VRT_r_req_xid,err_code 403, err_reason Request denied | -------------------------------------------------------------------+-------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: This is fixed in r3183 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 18:56:29 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 18:56:29 -0000 Subject: [Varnish] #318: Bug when 302 redirect used on ESI page In-Reply-To: <053.9170b917a29ae357e742b547056a0600@projects.linpro.no> References: <053.9170b917a29ae357e742b547056a0600@projects.linpro.no> Message-ID: <062.7dccfc0672cd2b9bbd00af985bb86f29@projects.linpro.no> #318: Bug when 302 redirect used on ESI page ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in r3193 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 16 19:00:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 16 Sep 2008 19:00:37 -0000 Subject: [Varnish] #284: Child [] Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476 In-Reply-To: <048.d9cc14005f21c6485d454c73891ba1cb@projects.linpro.no> References: <048.d9cc14005f21c6485d454c73891ba1cb@projects.linpro.no> Message-ID: <057.ce9cdc8dfb78281f9c664d64b39a5a6d@projects.linpro.no> #284: Child [] Panic message: Assert error in VRT_r_server_ip(), cache_vrt.c line 476 ----------------------+----------------------------------------------------- Reporter: wg | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in r3194 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 17 01:16:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Sep 2008 01:16:50 -0000 Subject: [Varnish] #320: ESI fails with POST fails Message-ID: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Where the URL is requested with POST, the ESI fails. {{{ sub vcl_recv { # Handle special requests if (req.request != "GET" && req.request != "HEAD") { # POST - Logins and edits if (req.request == "POST") { pass; } } }}} The backend is not touched according to Apache Logs. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 17 17:32:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 17 Sep 2008 17:32:38 -0000 Subject: [Varnish] #321: hild (4945) Panic message: Assert error in EXP_Touch(), cache_expire.c line 206: Message-ID: <049.e144e52043f1621b2c25b91f9073f773@projects.linpro.no> #321: hild (4945) Panic message: Assert error in EXP_Touch(), cache_expire.c line 206: -------------------+-------------------------------------------------------- Reporter: sky | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- {{{ Child (4945) Panic message: Assert error in EXP_Touch(), cache_expire.c line 206: Condition((oe)->magic == 0x4d301302) not true. thread = (cache- worker)sp = 0x1b96ca08 { fd = 423, id = 423, xid = 543071192, client = 66.130.16.181:63092, step = STP_DELIVER, handling = PASS, err_code = 301, err_reason = (null), ws = 0x1b96ca78 { id = "sess", {s,f,r,e} = {0x1b96d1a0,,+1212,(nil),+32768}, }, worker = 0x7e862c00 { }, vcl = { srcname = { "/home/artur/wikia-beta.vcl", "Default", }, }, obj = 0x2aab11037000 { refcnt = 1, xid = 543071192, ws = 0x2aab11037028 { id = "obj", {s,f,r,e} = {0x2aab11037350,,+615,(nil),+31920}, }, http = { ws = 0x2aab11037028 { id = "obj", {s,f,r,e} = {0x2aab11037350,,+615,(nil),+31920}, }, hd = { "Date: Wed, 17 Sep 2008 17:14:19 GMT", "Server: Apache", "X-Powered-By: PHP/5.2.6", "Vary: Accept-Encoding,Cookie", "X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string- contains=wikicitiesToken;string-contains=wikicitiesLoggedOut;string- contains=wikicities_session", "Expires: Thu, 01 Jan 1970 00:00:00 GMT", "Cache-Control: private, must-revalidate, max-age=0", "Last-modified: Wed, 17 Sep 2008 17:14:19 GMT", "Location: http://www.wowwiki.com/Dragonkin", "Content-Encoding: gzip", "Content-Type: text/html; charset=utf-8", "Content-Length: 20", "X-Orighost: www.wowwiki.com", "X-Cacheable: NO:Not-Cacheable", }, }, len = 20, store = { 20 { 1f 8b 08 00 00 00 00 00 00 03 03 00 00 00 00 00 |................| 00 00 00 00 |....| }, }, }, }, }}} Going to try and capture in GDB and print *oe and oe->magic -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 18 11:07:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Sep 2008 11:07:17 -0000 Subject: [Varnish] #322: PATCH: Enable mmap of devices if running Linux Message-ID: <052.ffa19126ee12cef63c68d21dd7d50c60@projects.linpro.no> #322: PATCH: Enable mmap of devices if running Linux -------------------------+-------------------------------------------------- Reporter: petter | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: -------------------------+-------------------------------------------------- This patch enables block devices to be opened withe the file storage option on Linux. It is not 100% tested, so no guarantees. To use a block device as storage, use the option -s file,/dev/somedevice,100% You must add "100%", otherwise only 50% will be used, and emember to ABSOLUTELY sure you have selected the right device, otherwise you WILL loose data. This patch is for r3197 of storage_file.c -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 18 11:10:15 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Sep 2008 11:10:15 -0000 Subject: [Varnish] #322: PATCH: Enable mmap of devices if running Linux In-Reply-To: <052.ffa19126ee12cef63c68d21dd7d50c60@projects.linpro.no> References: <052.ffa19126ee12cef63c68d21dd7d50c60@projects.linpro.no> Message-ID: <061.52f7de4c167c96f1f7a95c511f9df24c@projects.linpro.no> #322: PATCH: Enable mmap of devices if running Linux -------------------------+-------------------------------------------------- Reporter: petter | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by perbu): * cc: ay at vg.no (added) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 18 12:11:13 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Sep 2008 12:11:13 -0000 Subject: [Varnish] #322: PATCH: Enable mmap of devices if running Linux In-Reply-To: <052.ffa19126ee12cef63c68d21dd7d50c60@projects.linpro.no> References: <052.ffa19126ee12cef63c68d21dd7d50c60@projects.linpro.no> Message-ID: <061.368120b94c518aff287399518e2a6c1b@projects.linpro.no> #322: PATCH: Enable mmap of devices if running Linux -------------------------+-------------------------------------------------- Reporter: petter | Owner: Type: enhancement | Status: new Priority: normal | Milestone: After 2.0 Component: build | Version: trunk Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * milestone: => After 2.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 18 19:53:08 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 18 Sep 2008 19:53:08 -0000 Subject: [Varnish] #323: Remove tcl requirement to build Message-ID: <054.31b8450a6c811f984e808b07be5dd80a@projects.linpro.no> #323: Remove tcl requirement to build ----------------------+----------------------------------------------------- Reporter: The_ZoRo | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ----------------------+----------------------------------------------------- it's only there if you've touched the .tcl or include/*.h files after the generated .c files, so not everybody will see the problem. As promised :) /ZoRo -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 19 12:17:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Sep 2008 12:17:56 -0000 Subject: [Varnish] #323: Remove tcl requirement to build In-Reply-To: <054.31b8450a6c811f984e808b07be5dd80a@projects.linpro.no> References: <054.31b8450a6c811f984e808b07be5dd80a@projects.linpro.no> Message-ID: <063.de13753b83e53b228059f985e25ce070@projects.linpro.no> #323: Remove tcl requirement to build ----------------------+----------------------------------------------------- Reporter: The_ZoRo | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in commit 3202. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 19 13:08:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Sep 2008 13:08:37 -0000 Subject: [Varnish] #324: Full freeze Message-ID: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- When I subject Varnish to a lot of load I can get I to freeze. Only the HTTP server freezes. The child responds to pings. {{{ Revision: 3201 OS: Centos 5 (2.6.18-92.1.10.el5) and Ubuntu Hardy (2.6.24-19-generic, 2.6.24-19-server) Commandline: varnish ishd -s file,/var/varnish-cache/cache,20% -a 0.0.0.0:80 -b localhost:8080 -T localhost:2000 -d }}} I also tried with malloc and the experimental "raw device" patch (#322). Same result. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 19 13:16:51 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Sep 2008 13:16:51 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.543632a42f7a23df746c8f98bbd7bfd8@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by perbu): * cc: perbu at linpro.no (added) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 19 13:19:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Sep 2008 13:19:22 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.685c9219fbe0155d14fd2e7535117ccd@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by perbu): More on the setup: Varnish in setup in front of Apache 2.2 or Nginx. Default configuration. It serves 64MB big files through varnish. Siege is used to stress it. siege -c 10 -b -i -t1m -l -f urls-128.txt -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 19 16:22:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Sep 2008 16:22:39 -0000 Subject: [Varnish] #325: assert bug error - trunk r3102 Message-ID: <050.425f10f010447ee093ebf4ff154e08c5@projects.linpro.no> #325: assert bug error - trunk r3102 -------------------+-------------------------------------------------------- Reporter: alex | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------+-------------------------------------------------------- hello chaps, had a bug today with trunk r-3102, ive included the errors here: child (8803) Started Child (8803) said Closed fds: 4 6 10 11 13 14 Child (8803) said Child starts Child (8803) said managed to mmap 169279488 bytes of 169279488 Child (8803) said Ready Child (8803) died signal=6 Child (8803) Panic message: Assert error in Tcheck(), cache.h line 671: Condition((t.b) != 0) not true. thread = (cache-worker)sp = 0x87e8b5c { fd = 10, id = 10, xid = 1302308084, client = 172.31.101.23:3184, step = STP_FETCH, handling = FETCH, ws = 0x87e8ba4 { id = "sess", {s,f,r,e} = {0x87e9024,,+727,(nil),+8192}, }, worker = 0x9f7d0170 { }, vcl = { srcname = { "/etc/varnish/mt.nvweb1.vcl.0001", "Default", }, }, obj = 0xa65dc000 { refcnt = 1, xid = 1302308084, ws = 0xa65dc018 { id = "obj", {s,f,r,e} = {0xa65dc1e4,,0xa65dc1e4,(nil),+7708}, }, http = { ws = 0xa65dc018 { id = "obj", {s,f,r,e} = {0xa65dc1e4,,0xa65dc1e4,(nil),+7708}, }, }, len = 0, store = { }, }, }, ############ GDB crash: trace: http://pastebin.com/m21a25556 my config: http://pastebin.com/m2b986796 ########################### seems that if i were to goto a cgi regex match it would varnish would crash, however, going to the "/tag/" regex match it would _not_ assert crash. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 19 16:29:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Sep 2008 16:29:39 -0000 Subject: [Varnish] #325: assert bug error - trunk r3102 In-Reply-To: <050.425f10f010447ee093ebf4ff154e08c5@projects.linpro.no> References: <050.425f10f010447ee093ebf4ff154e08c5@projects.linpro.no> Message-ID: <059.8fa8f55a34023b75878c16ddfeb73c84@projects.linpro.no> #325: assert bug error - trunk r3102 --------------------+------------------------------------------------------- Reporter: alex | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Old description: > hello chaps, > > had a bug today with trunk r-3102, ive included the errors here: > > child (8803) Started > Child (8803) said Closed fds: 4 6 10 11 13 14 > Child (8803) said Child starts > Child (8803) said managed to mmap 169279488 bytes of 169279488 > Child (8803) said Ready > Child (8803) died signal=6 > Child (8803) Panic message: Assert error in Tcheck(), cache.h line 671: > Condition((t.b) != 0) not true. thread = (cache-worker)sp = 0x87e8b5c > { > fd = 10, id = 10, xid = 1302308084, > client = 172.31.101.23:3184, > step = STP_FETCH, > handling = FETCH, > ws = 0x87e8ba4 { > id = "sess", > {s,f,r,e} = {0x87e9024,,+727,(nil),+8192}, > }, > worker = 0x9f7d0170 { > }, > vcl = { > srcname = { > "/etc/varnish/mt.nvweb1.vcl.0001", > "Default", > }, > }, > obj = 0xa65dc000 { > refcnt = 1, xid = 1302308084, > ws = 0xa65dc018 { > id = "obj", > {s,f,r,e} = {0xa65dc1e4,,0xa65dc1e4,(nil),+7708}, > }, > http = { > ws = 0xa65dc018 { > id = "obj", > {s,f,r,e} = {0xa65dc1e4,,0xa65dc1e4,(nil),+7708}, > }, > }, > len = 0, > store = { > }, > }, > }, > > ############ GDB crash: trace: http://pastebin.com/m21a25556 > > > my config: > > http://pastebin.com/m2b986796 > > ########################### > > seems that if i were to goto a cgi regex match it would varnish would > crash, however, going to the "/tag/" regex match it would _not_ assert > crash. New description: hello chaps, had a bug today with trunk r-3102, ive included the errors here: {{{ child (8803) Started Child (8803) said Closed fds: 4 6 10 11 13 14 Child (8803) said Child starts Child (8803) said managed to mmap 169279488 bytes of 169279488 Child (8803) said Ready Child (8803) died signal=6 Child (8803) Panic message: Assert error in Tcheck(), cache.h line 671: Condition((t.b) != 0) not true. thread = (cache-worker)sp = 0x87e8b5c { fd = 10, id = 10, xid = 1302308084, client = 172.31.101.23:3184, step = STP_FETCH, handling = FETCH, ws = 0x87e8ba4 { id = "sess", {s,f,r,e} = {0x87e9024,,+727,(nil),+8192}, }, worker = 0x9f7d0170 { }, vcl = { srcname = { "/etc/varnish/mt.nvweb1.vcl.0001", "Default", }, }, obj = 0xa65dc000 { refcnt = 1, xid = 1302308084, ws = 0xa65dc018 { id = "obj", {s,f,r,e} = {0xa65dc1e4,,0xa65dc1e4,(nil),+7708}, }, http = { ws = 0xa65dc018 { id = "obj", {s,f,r,e} = {0xa65dc1e4,,0xa65dc1e4,(nil),+7708}, }, }, len = 0, store = { }, }, }, ############ GDB crash: trace: http://pastebin.com/m21a25556 my config: http://pastebin.com/m2b986796 ########################### }}} seems that if i were to goto a cgi regex match it would varnish would crash, however, going to the "/tag/" regex match it would _not_ assert crash. Comment: Fixed in r3203, the problem is the missing reason string from your backend which the code had degenerated to not handling. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 19 20:50:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 19 Sep 2008 20:50:49 -0000 Subject: [Varnish] #309: Varnish freezes if >1k of binary postdata is passed in In-Reply-To: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> References: <053.07d425460ca3ffecdd683f2353df91c6@projects.linpro.no> Message-ID: <062.67ac4e6c13ba62c4cd30962159c898ff@projects.linpro.no> #309: Varnish freezes if >1k of binary postdata is passed in ---------------------+------------------------------------------------------ Reporter: Fry-kun | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.0 release Component: build | Version: 2.0 Severity: normal | Resolution: worksforme Keywords: | ---------------------+------------------------------------------------------ Comment (by phk): On indications that Expect might be giving us problems in certain scenarios, I took the time to implement it quite properly. Fixed in r3206 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Sep 20 09:47:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Sep 2008 09:47:14 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.c8c821b295639681e4731de89a738630@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): As far as I can see, the situation is: {{{ Thread 11 (the acceptor) is scheduling workrequest 0x9ae04b0 containing session 0x9ae0338 on the threadpool 0x9aa3260 having picked worker 0x47134c10 Which is closest to thread 6, based on wlb address Thread 6 is not first in queue so thread 3, 4 & 5 would have managed to get the mutex since. And thread 6 seems to be _on_ the queue which should be impossible. Varnishlog contains: 0 WorkThread - 0x47134c10 end The smoking gun... ? Thread 9 can not be the target even though wrq member being set to 0x9ae04b0 it is in the wrong pool and ww->wrq == NULL so the wrq content is leftovers from last There is no sign anybody is holding the wq mutex (0x9aa3268) Yet Thread 11 seems to be stuck on it guess based on: "in __lll_mutex_lock_wait ()" I notice, that all condvars in the workers have "__nwaiters = 2" I would have expected a value of one, as the condvar is private to the worker thread. This may be a quirk of the pthreads implementation. Thread 3 and 4 look suspect, in that they seem to have the exact same condvar. The other private data seems to be truly private. This could also be a quirk of the pthreads implementation. If condvars are pooled I have a hard time seeing how resolution would work based on the recorded data This condvar also has __nwaiters = 2, should be 3 if the condvar was shared ? Suspect These threads are in the subject pool Or could just be accidentally that they have the same sequence# not unlikely And futex# somewhat unlikely And __align garbage somewhat unlikely not a credible hypothesis The two threads have last-used very close to each other: 0.215452 msec apart. All the worker-threads are idle. Queue orders seems to be: wq = 0x9aa3260 4 vtqe_next = #3 0x49938c10, vtqe_prev = #H 0x9aa3290 1221835916.0777061 wlb = 0x48f35c00 3 vtqe_next = #5 0x48536c10, vtqe_prev = #4 0x48f37c60 1221835916.077179 wlb = 0x49936c00 5 vtqe_next = #6 0x47b35c10, vtqe_prev = #3 0x49938c60 1221835916.0561609 wlb = 0x48534c00 6 vtqe_next = #2 0x4a339c10, vtqe_prev = #5 0x48536c60 1221835915.8512189 wlb = 0x47b33c00 2 vtqe_next = #T 0x0, vtqe_prev = #6 0x47b35c60 1221835915.694943 wlb = 0x4a337c00 wq = 0x9aa1180 7 vtqe_next = #13 0x42b2dc10, vtqe_prev = #H 0x9aa11b0 1221835916.218838 wlb = 0x46731c00 13 vtqe_next = #8 0x45d32c10, vtqe_prev = #7 0x46733c60 1221835916.167063 wlb = 0x42b2bc00 8 vtqe_next = #10 0x44930c10, vtqe_prev = #13 0x42b2dc60 1221835916.020401 wlb = 0x45d30c00 10 vtqe_next = #9 0x45331c10, vtqe_prev = #8 0x45d32c60 1221835915.992481 wlb = 0x4492ec00 9 vtqe_next = #T 0x0, vtqe_prev = #10 0x44930c60 1221835915.676183 wlb = 0x4532fc00 Varnishlog: 0 WorkThread - 0x42b2dc10 start = #13 0 WorkThread - 0x44930c10 start = #10 0 WorkThread - 0x45331c10 start = #9 0 WorkThread - 0x45d32c10 start = #8 0 WorkThread - 0x46733c10 start = #7 0 WorkThread - 0x47134c10 start 0 WorkThread - 0x47b35c10 start = #6 0 WorkThread - 0x48536c10 start = #5 0 WorkThread - 0x48f37c10 start = #4 0 WorkThread - 0x49938c10 start = #3 0 WorkThread - 0x4a339c10 start = #2 0 WorkThread - 0x47134c10 end }}} There seems to be no reason to hang on the mutex Two threads seem to share a condvar The picked thread seems to have been (in the process off) being decimated. None of this makes sense. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sat Sep 20 10:16:15 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sat, 20 Sep 2008 10:16:15 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.086f75a2f6ae917453302c271ffdde50@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: I hate to do blameallocation, but it looks like either a hardware or a pthread implementation issue. The shared cond-var makes me suspect the pthread implementation more than hardware, but hardware issues with respect to atomic instructions would tilt any good pthread implementation. Whatever it is, I see nothing that I can correlate to deficiencies in the varnish source code at this point. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 21 01:27:38 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 21 Sep 2008 01:27:38 -0000 Subject: [Varnish] #326: ESI with #326: ESI with tag, varnish will send a content chunk with 0 length, therefore the client thinks no more is coming -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 21 06:49:59 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 21 Sep 2008 06:49:59 -0000 Subject: [Varnish] #326: ESI with References: <049.4ef8c7167f49c0a898260b2885e0c851@projects.linpro.no> Message-ID: <058.7fa6aed7c5d78443243c7c8d4b5321a8@projects.linpro.no> #326: ESI with closed * resolution: => fixed Comment: Fixed in r3208 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 21 07:37:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 21 Sep 2008 07:37:22 -0000 Subject: [Varnish] #266: Fix bug in ESI parser In-Reply-To: <049.5a702ebbeffb03c04eb383b85060649d@projects.linpro.no> References: <049.5a702ebbeffb03c04eb383b85060649d@projects.linpro.no> Message-ID: <058.d87f7e3acba63c7bf7479206652c98ef@projects.linpro.no> #266: Fix bug in ESI parser ----------------------+----------------------------------------------------- Reporter: sky | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: The patch is not correct, a check for " Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 21 14:19:03 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 21 Sep 2008 14:19:03 -0000 Subject: [Varnish] #327: varnishd fails to parse config, reporting "Backend port '"8080"': Name or service not known" Message-ID: <056.d972afefa1584c6b5ee2d28a1a44963f@projects.linpro.no> #327: varnishd fails to parse config, reporting "Backend port '"8080"': Name or service not known" ------------------------+--------------------------------------------------- Reporter: nheinrichs | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ------------------------+--------------------------------------------------- I downloaded 2.0 beta 1 from SourceForge and installed on Ubuntu 8.04 per instructions on wiki. Copied this bit out of ./etc/default.vcl in the build directory and saved to /etc/conf.vcl: {{{ backend default { .host = "127.0.0.1"; .port = "8080"; } }}} Attempted to run server and get this error every time. I have tried "8080", "80", "www", "http" and get the same error every time. I am running as root, /etc/services is accessible: {{{ root at staging-web01:/root/varnish-2.0-beta1 # varnishd -f /etc/conf.vcl Backend port '"8080"': Name or service not known (/etc/conf.vcl Line 3 Pos 9) .port = "8080"; --------######- In backend specfication starting at: (/etc/conf.vcl Line 1 Pos 1) backend default { #######---------- VCL compilation failed root at staging-web01:/root/varnish-2.0-beta1 # }}} Any ideas appreciated. Thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 21 15:09:13 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 21 Sep 2008 15:09:13 -0000 Subject: [Varnish] #327: varnishd fails to parse config, reporting "Backend port '"8080"': Name or service not known" In-Reply-To: <056.d972afefa1584c6b5ee2d28a1a44963f@projects.linpro.no> References: <056.d972afefa1584c6b5ee2d28a1a44963f@projects.linpro.no> Message-ID: <065.7b1fb5bb297d792257856f86ffb5cc6e@projects.linpro.no> #327: varnishd fails to parse config, reporting "Backend port '"8080"': Name or service not known" ------------------------+--------------------------------------------------- Reporter: nheinrichs | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by nheinrichs): Adding the string 'localhost' to the entry for 127.0.0.1 in /etc/hosts on the server solved this issue. Please close this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 07:46:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 07:46:22 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.42846babe25a6c6e785370bc551925e6@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by wichert): * status: closed => reopened * resolution: fixed => Comment: We are unfortunately seeing the problem again with varnish at r3020. We'll test if 2.0beta improves things. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 08:04:06 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 08:04:06 -0000 Subject: [Varnish] #328: 2.0-beta1 does not compile on OSX 10.4 Message-ID: <053.dda82ed418522d122cf3ffe5c5eee227@projects.linpro.no> #328: 2.0-beta1 does not compile on OSX 10.4 ---------------------+------------------------------------------------------ Reporter: wichert | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | ---------------------+------------------------------------------------------ {{{ gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -DVARNISH_STATE_DIR='"/Users/wichert/Development/psol/elkjop/buildout/proxy/trunk/parts /varnish-build/install/var/varnish"' -g -O2 -MT varnishd-cache_vrt_acl.o -MD -MP -MF .deps/varnishd-cache_vrt_acl.Tpo -c -o varnishd- cache_vrt_acl.o `test -f 'cache_vrt_acl.c' || echo './'`cache_vrt_acl.c In file included from cache.h:52, from cache_vrt_acl.c:39: heritage.h:74: error: parse error before 'uid_t' heritage.h:74: warning: no semicolon at end of struct or union heritage.h:181: error: parse error before '}' token make[2]: *** [varnishd-cache_vrt_acl.o] Error 1 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 08:04:31 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 08:04:31 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.5d8ee6fb682722a51628d9bc461bd701@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Can you please provide a snapshot of varnishstat output when this happens. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 08:05:18 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 08:05:18 -0000 Subject: [Varnish] #328: 2.0-beta1 does not compile on OSX 10.4 In-Reply-To: <053.dda82ed418522d122cf3ffe5c5eee227@projects.linpro.no> References: <053.dda82ed418522d122cf3ffe5c5eee227@projects.linpro.no> Message-ID: <062.4ec7d76a8cfeb097b7ba2e51db3d7872@projects.linpro.no> #328: 2.0-beta1 does not compile on OSX 10.4 ---------------------+------------------------------------------------------ Reporter: wichert | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by phk): Please check if this is fixed in -trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 08:15:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 08:15:49 -0000 Subject: [Varnish] #327: varnishd fails to parse config, reporting "Backend port '"8080"': Name or service not known" In-Reply-To: <056.d972afefa1584c6b5ee2d28a1a44963f@projects.linpro.no> References: <056.d972afefa1584c6b5ee2d28a1a44963f@projects.linpro.no> Message-ID: <065.8a2c780695ba8f0de3fa764861d23661@projects.linpro.no> #327: varnishd fails to parse config, reporting "Backend port '"8080"': Name or service not known" ------------------------+--------------------------------------------------- Reporter: nheinrichs | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Fixed in r3211 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 09:35:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 09:35:12 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.d5ed3a1083b53470a612c5701df4ff82@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by perbu): * status: closed => reopened * resolution: worksforme => Comment: I am unable to reproduce this on FreeBSD 7.0 RELEASE. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 09:42:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 09:42:57 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.2f10fd92af66e2b8807161407ea8d7a8@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by perbu): Action points: We need to check whether the bug is bound to NTPL (LD_ASSUME_KERNEL=2.4.19 should do this). Futhermore, PHK suggests running under Valgrind. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 09:46:00 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 09:46:00 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.91fbf0e7650e071730143b37debd80dd@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Just a clarification on Valgrind: It's the pthread checker I'm interested in, not the memory checker. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 09:55:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 09:55:25 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.06dd3292d63596e43eb5bd73e6513baf@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by perbu): How the tests are done. The backend (nginx or apache, tried both) serves a lot of 64M big files (dd if=/dev/zero of=1 bs=1M count=64, then I create a lot of hardlinkes to the same file .. named 1 .. 1024). siege in benchmark mode is used to hammer on varnish. siege -c 20 -b -i -f urls-1024.txt -t1h urls-1024.txt goes like this: http://87.238.44.78/1 http://87.238.44.78/2 http://87.238.44.78/3 http://87.238.44.78/4 http://87.238.44.78/5 http://87.238.44.78/6 http://87.238.44.78/7 http://87.238.44.78/8 http://87.238.44.78/9 http://87.238.44.78/10 http://87.238.44.78/11 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 10:10:04 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 10:10:04 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.9b8f636a1ceb8ec22e18b79f336d450f@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): Random list of things to try for the lack of a better clue: Capture a varnishstat snapshot when it fails. Do binary search on number of test-files, to see if there is a threshold where the problem appears, in particular look for effects as working set size hovers around RAM size. Try other count/size combinations, 512 files @ 128M, 2048 files @ 32M etc. Try binary search on number of clients to see if there is a threshold Set very long/short TTL on objects in VCL to see if expiry is involved. Disable some CPU cores and see how that changes the picture. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 13:37:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 13:37:07 -0000 Subject: [Varnish] #308: Worker threads reported 0 In-Reply-To: <049.5aeeeeb54ccb74dfc40ac59a38ead667@projects.linpro.no> References: <049.5aeeeeb54ccb74dfc40ac59a38ead667@projects.linpro.no> Message-ID: <058.2109e43d5608192719ecee3f66111978@projects.linpro.no> #308: Worker threads reported 0 --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by perbu): * status: closed => reopened * resolution: fixed => Comment: This broke varnish on linux. We need (?) another fix. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 13:41:10 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 13:41:10 -0000 Subject: [Varnish] #324: Full freeze In-Reply-To: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> References: <051.574658b4248654f02c603ee2bdef7823@projects.linpro.no> Message-ID: <060.a3ec7049ae285e8542db7a686d3d0f4b@projects.linpro.no> #324: Full freeze ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.0 release Component: varnishd | Version: trunk Severity: blocker | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by perbu): * status: reopened => closed * resolution: => fixed Comment: Fixed in r3213. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 14:35:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 14:35:21 -0000 Subject: [Varnish] #308: Worker threads reported 0 In-Reply-To: <049.5aeeeeb54ccb74dfc40ac59a38ead667@projects.linpro.no> References: <049.5aeeeeb54ccb74dfc40ac59a38ead667@projects.linpro.no> Message-ID: <058.9eda165cef452c06b8fa38711e3a366a@projects.linpro.no> #308: Worker threads reported 0 --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment (by phk): I overlooked a detail in this patch when I reviewed it, and thus it caused #324. r3213 fixes both this and #324. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 22 16:21:32 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 22 Sep 2008 16:21:32 -0000 Subject: [Varnish] #329: Increase cli_timeout Message-ID: <051.3b6b0962ee9b02647c61c97575193e77@projects.linpro.no> #329: Increase cli_timeout ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: trivial | Keywords: cli_timeout ----------------------+----------------------------------------------------- Whilst benchmarking I've several times ran into the cli_timeout. Can we increase it a little? Is there a down-side? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 23 08:55:36 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Sep 2008 08:55:36 -0000 Subject: [Varnish] #328: 2.0-beta1 does not compile on OSX 10.4 In-Reply-To: <053.dda82ed418522d122cf3ffe5c5eee227@projects.linpro.no> References: <053.dda82ed418522d122cf3ffe5c5eee227@projects.linpro.no> Message-ID: <062.f5895c819c902c3d9f95c36e4ec61918@projects.linpro.no> #328: 2.0-beta1 does not compile on OSX 10.4 ---------------------+------------------------------------------------------ Reporter: wichert | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by wichert): Current trunk compiles fine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 23 09:11:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Sep 2008 09:11:16 -0000 Subject: [Varnish] #328: 2.0-beta1 does not compile on OSX 10.4 In-Reply-To: <053.dda82ed418522d122cf3ffe5c5eee227@projects.linpro.no> References: <053.dda82ed418522d122cf3ffe5c5eee227@projects.linpro.no> Message-ID: <062.913875bd587b7a79563a6fbecf2a4d37@projects.linpro.no> #328: 2.0-beta1 does not compile on OSX 10.4 ---------------------+------------------------------------------------------ Reporter: wichert | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: worksforme Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => worksforme -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 23 11:28:05 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Sep 2008 11:28:05 -0000 Subject: [Varnish] #329: Increase cli_timeout In-Reply-To: <051.3b6b0962ee9b02647c61c97575193e77@projects.linpro.no> References: <051.3b6b0962ee9b02647c61c97575193e77@projects.linpro.no> Message-ID: <060.144e23662ca071717eb6b0af59baa335@projects.linpro.no> #329: Increase cli_timeout -------------------------+-------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: trivial | Resolution: Keywords: cli_timeout | -------------------------+-------------------------------------------------- Comment (by phk): The cli_timeout acts a check to see if the worker thread is still alive. The intention behind the relatively short timeout, is to be able to kill and restart the worker process in "a few seconds". As such the only downside to increasing it, is to make for a longer outage, if the process croaks. You are not the only one to see evidence of timeouts, mostly due to kernel/disk activity, so I think increasing a bit is called for. Now to define "a bit". I would say that 10 seconds is too long (given the usual web-users patience). The question is if 5 seconds is long enough to avoid false shootdowns. Input from the real world would be much appreciated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 23 11:31:00 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Sep 2008 11:31:00 -0000 Subject: [Varnish] #321: hild (4945) Panic message: Assert error in EXP_Touch(), cache_expire.c line 206: In-Reply-To: <049.e144e52043f1621b2c25b91f9073f773@projects.linpro.no> References: <049.e144e52043f1621b2c25b91f9073f773@projects.linpro.no> Message-ID: <058.64885c7a6dfd4f1222a25412e5e3c40b@projects.linpro.no> #321: hild (4945) Panic message: Assert error in EXP_Touch(), cache_expire.c line 206: --------------------+------------------------------------------------------- Reporter: sky | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by phk): Do you know if this was trunk was from 3188 to 3212 (incl). ? If so I would attribute this bug to the same problem as #324 and close this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 23 11:35:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Sep 2008 11:35:41 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.93d829596ff75beb92a10d16b8fdd233@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I have a little bit of trouble understanding what is going on here, can you elaborate a little bit on the exact request and object contents so I can try to reproduce it ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 23 14:30:03 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 23 Sep 2008 14:30:03 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.c88dc776801adc81f81f3b86283087db@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kierank): Yes, basically process.php (in the typescript) is a PHP script that processes user registrations. So the username/pass/email etc. is passed through POST. If the registration fails (e.g invalid email address etc.) then process.php chucks out an error page. This page has ESI on it. The ESI on this page does not work (and this I think this is because the request is a POST request not a GET request - pages with GET work fine). The error message is: {{{ Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 821226879 Varnish }}} The logs of Apache show that no request for the ESI page is ever made. Running trunk on Ubuntu Server 8.04 LTS. Please don't hesitate to ask more questions... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 03:14:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 03:14:01 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.6044fdfa51d92d161ab398d935e80ced@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): I try do a test again . This is a report Environment: FreeBSD 7.0-RELEASE amd64 ,SCHED_ULE ,filesystem Turn off soft-updates and noatime Varnish version : trunk revision: 3213 Test tool: http_load ,version 12mar2006 urls count : 155573 http_load command: {{{ [root at localhost http_load-12mar2006]# ./http_load -proxy varnish_host_ip:80 -parallel 500 -seconds 600 siege_url.txt ...... http://image2.XXX.com.cn/igame/new/new015/shop_index_67.gif: byte count wrong http://i2.XXXimg.cn/gm/http/blog.XXX.com.cn/s/U2217P115T146D16346F4314DT20080918102123_w80.jpg: byte count wrong http://image2.XXX.com.cn/music/artist/0/1200_200150.jpg: byte count wrong http://image2.XXX.com.cn/music/artist/0/1200_200150.jpg: byte count wrong http://i3.XXXimg.cn/qc/buy/U121P33T133D11263F1620DT20080917103216.jpg: byte count wrong http://i2.XXXimg.cn/IT/mobile/models/U1069P2T136D2764F3244DT20050526165505_150h.jpg: byte count wrong http://i2.XXXimg.cn/IT/cr/2008/0229/1730605940.jpg: byte count wrong http://i0.XXXimg.cn/lx/fa/p/2008/0805/U1562P8T1D750071F915DT20080805114645.jpg: byte count wrong http://image2.XXX.com.cn/download/ebook/2004-11-22/U74P176T13D5119F197DT20041122113641.gif: byte count wrong ...... 290320 fetches, 500 max parallel, 4.36283e+09 bytes, in 600 seconds 15027.6 mean bytes/connection 483.866 fetches/sec, 7.27137e+06 bytes/sec msecs/connect: 46.4545 mean, 6003.24 max, 0.219 min msecs/first-response: 788.459 mean, 59985.5 max, 0.349 min 574 timeouts 2398 bad byte counts HTTP response codes: code 200 -- 285218 code 301 -- 7 code 400 -- 2 code 403 -- 939 code 404 -- 1968 code 503 -- 112 }}} log info: {{{ Sep 23 06:28:38 HP08020020 varnishd[25386]: child (25387) Started Sep 23 06:28:38 HP08020020 varnishd[25386]: Child (25387) said Closed fds: 7 8 11 12 14 15 Sep 23 06:28:38 HP08020020 varnishd[25386]: Child (25387) said Child starts Sep 23 06:28:38 HP08020020 varnishd[25386]: Child (25387) said managed to mmap 32212254720 bytes of 32212254720 Sep 23 06:28:38 HP08020020 last message repeated 3 times Sep 23 06:28:38 HP08020020 varnishd[25386]: Child (25387) said Ready Sep 23 08:42:34 HP08020020 varnishd[25386]: Child (25387) not responding to ping, killing it. Sep 23 08:42:34 HP08020020 kernel: pid 25387 (varnishd), uid 65534: exited on signal 3 Sep 23 08:42:34 HP08020020 varnishd[25386]: child (31998) Started Sep 23 08:42:35 HP08020020 varnishd[25386]: Child (31998) said Closed fds: 7 8 11 12 14 15 Sep 23 08:42:35 HP08020020 varnishd[25386]: Child (31998) said Child starts Sep 23 08:42:35 HP08020020 varnishd[25386]: Child (31998) said managed to mmap 32212254720 bytes of 32212254720 Sep 23 08:42:35 HP08020020 last message repeated 3 times Sep 23 08:42:35 HP08020020 varnishd[25386]: Child (31998) said Ready Sep 23 08:43:19 HP08020020 varnishd[25386]: Child (31998) not responding to ping, killing it. Sep 23 08:43:49 HP08020020 last message repeated 3 times Sep 23 08:43:52 HP08020020 kernel: pid 31998 (varnishd), uid 65534: exited on signal 3 Sep 23 08:43:52 HP08020020 varnishd[25386]: child (32040) Started Sep 23 08:43:53 HP08020020 varnishd[25386]: Child (32040) said Closed fds: 7 8 11 12 14 15 Sep 23 08:43:53 HP08020020 varnishd[25386]: Child (32040) said Child starts Sep 23 08:43:53 HP08020020 varnishd[25386]: Child (32040) said managed to mmap 32212254720 bytes of 32212254720 Sep 23 08:43:53 HP08020020 last message repeated 3 times Sep 23 08:43:53 HP08020020 varnishd[25386]: Child (32040) said Ready Sep 23 08:44:21 HP08020020 cfexecd[667]: Cannot mail to root at sys.XXXX.com.cn. Sep 23 08:44:37 HP08020020 varnishd[25386]: Child (32040) not responding to ping, killing it. Sep 23 08:45:17 HP08020020 last message repeated 4 times Sep 23 08:45:19 HP08020020 kernel: pid 32040 (varnishd), uid 65534: exited on signal 3 Sep 23 08:45:19 HP08020020 varnishd[25386]: child (32100) Started Sep 23 08:45:19 HP08020020 varnishd[25386]: Child (32100) said Closed fds: 7 8 11 12 14 15 Sep 23 08:45:19 HP08020020 varnishd[25386]: Child (32100) said Child starts Sep 23 08:45:19 HP08020020 varnishd[25386]: Child (32100) said managed to mmap 32212254720 bytes of 32212254720 Sep 23 08:45:19 HP08020020 last message repeated 3 times Sep 23 08:45:19 HP08020020 varnishd[25386]: Child (32100) said Ready Sep 23 08:47:04 HP08020020 varnishd[25386]: Child (32100) not responding to ping, killing it. Sep 23 08:47:54 HP08020020 last message repeated 5 times Sep 23 08:47:58 HP08020020 kernel: pid 32100 (varnishd), uid 65534: exited on signal 3 Sep 23 08:47:58 HP08020020 varnishd[25386]: child (32210) Started Sep 23 08:47:58 HP08020020 varnishd[25386]: Child (32210) said Closed fds: 7 8 11 12 14 15 Sep 23 08:47:58 HP08020020 varnishd[25386]: Child (32210) said Child starts Sep 23 08:47:58 HP08020020 varnishd[25386]: Child (32210) said managed to mmap 32212254720 bytes of 32212254720 Sep 23 08:47:58 HP08020020 last message repeated 3 times Sep 23 08:47:58 HP08020020 varnishd[25386]: Child (32210) said Ready }}} system run status: {{{ system block,not response for a while and child killed and restarted again, threads reached about 550. After child restarted again, varnishstat show a little 'Client connections accepted' top command status: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 32100 nobody 555 44 0 120G 1425M STOP 2 0:27 0.00% varnishd gstat command status: 0 129 78 3325 8.8 51 815 6.5 42.7| ufs/data0 0 143 77 2941 8.8 66 1055 10.1 49.7| ufs/data1 5 112 57 2110 8.7 55 879 7.9 37.7| ufs/data2 4 141 78 2861 11.0 63 1007 8.5 46.6| ufs/data3 }}} varnish run command: {{{ varnishd -a 0.0.0.0:80 -f /usr/local/etc/vcl.conf \ -u nobody -g nobody \ -T 127.0.0.1:8080 \ -w 10,1000,600 \ -s file,/data0/varnish/v,30G \ -s file,/data1/varnish/v,30G \ -s file,/data2/varnish/v,30G \ -s file,/data3/varnish/v,30G \ -h classic,500009 \ -p thread_pools=4 \ -p listen_depth=4096 \ -p lru_interval=3600 \ -p ping_interval=10 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 06:39:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 06:39:17 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.1e335b773ddcd31cfe911c13b43ad737@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by phk): Try increasing the cli_timeout parameter and please report the lowest number that causes no restarts for you, we are actively considering if that paramter has too aggresive default value. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 07:06:45 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 07:06:45 -0000 Subject: [Varnish] #295: Varnishd using all available memory, even using limited malloc In-Reply-To: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> References: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> Message-ID: <057.3e018ace4ceadfee2df4fd3b4c893317@projects.linpro.no> #295: Varnishd using all available memory, even using limited malloc -------------------------------------+-------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: major | Resolution: Keywords: leak memory malloc swap | -------------------------------------+-------------------------------------- Comment (by brav0): I ran into the same problem yesterday, i started varnish with -s malloc,10G on a Linux ubuntu x64 box. I had to kill it when it was using over 14GB. Tried overloading with jemalloc and now it's stable at around 11GB. I am running yesterdays trunk. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 07:48:15 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 07:48:15 -0000 Subject: [Varnish] #295: Varnishd using all available memory, even using limited malloc In-Reply-To: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> References: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> Message-ID: <057.38a3084563b086e8a80312836d75e04b@projects.linpro.no> #295: Varnishd using all available memory, even using limited malloc -------------------------------------+-------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: major | Resolution: Keywords: leak memory malloc swap | -------------------------------------+-------------------------------------- Comment (by phk): Thankyou very much! This jives well with the sort of experiences the firefox project had when they switched to jemalloc, and with the fact that we see no such issues on FreeBSD servers. We have decided to import jemalloc and use that by default on the Linux platform. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 09:14:32 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 09:14:32 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error Message-ID: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> #330: 2.0-beta1 dies with accept error ---------------------+------------------------------------------------------ Reporter: wichert | Type: defect Status: new | Priority: highest Milestone: | Component: build Version: trunk | Severity: blocker Keywords: | ---------------------+------------------------------------------------------ We just had two varnish instances in load balancer setup die at the same time. varnishlog output showed lots and lots of these errors repeating at a very fast rate: {{{ 7 Debug - "Accept failed errno=24" 7 Debug - "Accept failed errno=24" 7 Debug - "Accept failed errno=24" 7 Debug - "Accept failed errno=24" }}} as soon as I attached strace to the process all threads died with SIGABRT. Looking at munin logs it appears that varnish was using many more network connections than ever before (100-120, while the average is around 10, with no change in access pattern that we know off) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 09:20:26 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 09:20:26 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error In-Reply-To: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> References: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> Message-ID: <062.f202b6dec7457b2e215ca116afdb5c8e@projects.linpro.no> #330: 2.0-beta1 dies with accept error ---------------------+------------------------------------------------------ Reporter: wichert | Owner: Type: defect | Status: new Priority: highest | Milestone: Component: build | Version: trunk Severity: blocker | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by wichert): I have varnishdlog output from the period during which this happened, but it seems varnishlog has problems reading it. An strace of it shows it is reading data but never printing anything: {{{ read(3, "Accept failed errno=24\0", 23) = 23 read(3, "\1\0\26\0\7", 5) = 5 read(3, "Accept failed errno=24\0", 23) = 23 read(3, "\1\0\26\0\7", 5) = 5 read(3, "Accept failed errno=24\0", 23) = 23 read(3, "\1\0\26\0\7", 5) = 5 }}} the uncompressed logfile is 2.8Gb in size. I can provide it to someone if required. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 09:26:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 09:26:25 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error In-Reply-To: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> References: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> Message-ID: <062.451e02634d25c3ab705c8d20f3f6a2ee@projects.linpro.no> #330: 2.0-beta1 dies with accept error ---------------------+------------------------------------------------------ Reporter: wichert | Owner: Type: defect | Status: closed Priority: highest | Milestone: Component: build | Version: trunk Severity: blocker | Resolution: worksforme Keywords: | ---------------------+------------------------------------------------------ Changes (by phk): * status: new => closed * resolution: => worksforme Comment: You have run out of file descriptors. Check your system resource limits (see ulimit(1)) The problem may also be caused by too many worker threads. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 09:29:01 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 09:29:01 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.8f2680646ddeff7f29e0a1e7d0221ad2@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): 2.0-beta1 shows the exact same behaviour, see #330 (which I'll close as a duplicate of this one) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 09:34:26 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 09:34:26 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error In-Reply-To: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> References: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> Message-ID: <062.3a8b57ea79ad6ec778a16eeee2072e02@projects.linpro.no> #330: 2.0-beta1 dies with accept error ---------------------+------------------------------------------------------ Reporter: wichert | Owner: Type: defect | Status: reopened Priority: highest | Milestone: Component: build | Version: trunk Severity: blocker | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by wichert): * status: closed => reopened * resolution: worksforme => Comment: The limit of open filehandles is set to 1024. On a lightly loaded server (dozen requests per second at most) it is surprising that this number would be reached unless. With a default of 2 thread pools and 500 threads per pool we might be close if varnish would never close a filehandle. I don't think varnish should use that many filehandles on this kind of load - it feels like a bug. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 09:47:46 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 09:47:46 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error In-Reply-To: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> References: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> Message-ID: <062.598a505375bef5e6777fb0795bed3f3d@projects.linpro.no> #330: 2.0-beta1 dies with accept error ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: low | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => new * severity: blocker => minor * component: build => varnishd * priority: highest => low * milestone: => After 2.0 * owner: => phk Comment: If this is a lightly loaded server, you should not have 1000 threads. The more threads you have surplus, the higher the risk of a thread pile-up if the backend hiccups or anything else goes wrong. Remember that varnish can need twice the number of concurrent requests filedescriptors if the requests need to get to the backend. If you think there is a problem, please provide more detail, in particular varnishstat and varnishlog output. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 09:54:06 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 09:54:06 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.1d5114b6c2d66967a8d5bdb28fa2ccd5@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): please check the error, I changed cli_timeout parameter and run 'purge.url .', for a while I find some error. log info: {{{ Sep 24 09:04:01 HP08020020 kernel: pid 7796 (varnishd), uid 65534: exited on signal 6 Sep 24 09:04:01 HP08020020 varnishd[7711]: Child (7796) Panic message: Assert error in exp_timer(), cache_expire.c line 303: Condition(oe2->timer_when >= oe->timer_when) not true. thread = (cache- timeout) }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 09:54:34 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 09:54:34 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error In-Reply-To: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> References: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> Message-ID: <062.3ff10d4c75b3d591d897cc6d69285c1b@projects.linpro.no> #330: 2.0-beta1 dies with accept error ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: low | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): As I said varnishlog chokes on the output it logged. I can provide you with the file itself (11mb compressed), but since it contains sensitive data I'll need an out-of-band channel to pass that on to you. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Sep 24 13:46:24 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 24 Sep 2008 13:46:24 -0000 Subject: [Varnish] #295: Varnishd using all available memory, even using limited malloc In-Reply-To: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> References: <048.ea710791e8668f55071568b187fd865f@projects.linpro.no> Message-ID: <057.b486bc40d5bfa491b5327db3bf98dbc9@projects.linpro.no> #295: Varnishd using all available memory, even using limited malloc -------------------------------------+-------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 release Component: build | Version: trunk Severity: major | Resolution: fixed Keywords: leak memory malloc swap | -------------------------------------+-------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: This should be fixed in r3216; please test and report back if it doesn't. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 25 03:24:31 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 25 Sep 2008 03:24:31 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.07b38fae91a8e1a9f999cf9c78d37a0e@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): why no core dump,I have setted kern.coredump = 1 and kern.sugid_coredump=1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 25 07:04:30 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 25 Sep 2008 07:04:30 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.0ca4c997ff30609b91cb5a513bb38607@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by ground): Replying to [comment:14 chenxy]: > why no core dump,I have setted > kern.coredump = 1 and kern.sugid_coredump=1 Did you check ulimit(1) -c option and add `-u root' option of varnishd? -- Ticket URL: Varnish The Varnish HTTP Accelerator From MAILER-DAEMON at projects.linpro.no Thu Sep 25 07:04:31 2008 From: MAILER-DAEMON at projects.linpro.no (Mail Delivery System) Date: Thu, 25 Sep 2008 09:04:31 +0200 (CEST) Subject: Undelivered Mail Returned to Sender Message-ID: <20080925070431.EA1421ED2CA@projects.linpro.no> This is the mail system at host projects.linpro.no. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : Host or domain name not found. Name service error for name=h.vom type=A: Host not found -------------- next part -------------- An embedded message was scrubbed... From: "Varnish" Subject: Re: [Varnish] #275: Varnish child stops responding Date: Thu, 25 Sep 2008 07:04:30 -0000 Size: 2632 URL: From varnish-bugs at projects.linpro.no Thu Sep 25 07:43:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 25 Sep 2008 07:43:12 -0000 Subject: [Varnish] #275: Varnish child stops responding In-Reply-To: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> References: <052.c197ec9345dac369784c70e85c4b85ec@projects.linpro.no> Message-ID: <061.f49d1467cf2fbe010e902a2dfbd1b954@projects.linpro.no> #275: Varnish child stops responding ---------------------------------+------------------------------------------ Reporter: chenxy | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: Varnish child stuck | ---------------------------------+------------------------------------------ Comment (by chenxy): thanks . gdb info: {{{ ...... [New Thread 0x8062029c0 (LWP 100144)] [New Thread 0x800f01850 (LWP 100143)] [New Thread 0x800f016e0 (LWP 100142)] [New Thread 0x806202850 (LWP 100141)] [New Thread 0x8062026e0 (LWP 100140)] [New Thread 0x806202570 (LWP 100139)] [New Thread 0x806202400 (LWP 100138)] [New Thread 0x806202290 (LWP 100137)] [New Thread 0x806202120 (LWP 100136)] [New Thread 0x800f01570 (LWP 100132)] [New Thread 0x800f01400 (LWP 100129)] [New Thread 0x800f01290 (LWP 100121)] [New Thread 0x800f01120 (LWP 100217)] (gdb) bt #0 0x0000000800d2efec in thr_kill () from /lib/libc.so.7 #1 0x0000000800db8c5b in abort () from /lib/libc.so.7 #2 0x0000000000420080 in pan_ic (func=Could not find the frame base for "pan_ic". ) at cache_panic.c:325 #3 0x0000000000416a3d in exp_timer (arg=0x0) at cache_expire.c:303 #4 0x0000000800ab6a88 in pthread_getprio () from /lib/libthr.so.3 #5 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffff7fd000 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 25 08:21:40 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 25 Sep 2008 08:21:40 -0000 Subject: [Varnish] #331: Varnish resends requests to backends after a restart Message-ID: <052.a26a914b192158b1ebc87683ea0f7c7c@projects.linpro.no> #331: Varnish resends requests to backends after a restart ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: new Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: critical | Keywords: ----------------------+----------------------------------------------------- I'm using varnish-2.0.beta2. Everything is ok but I found after I restart varnish, all requests will be sent to the backends as if all cached items are purged. I started varnish as: DAEMON_OPTS=" -a :80 \ -T localhost:6000 \ -f /etc/varnish/vcl.conf \ -u nobody -g nobody \ -n /data/varnish \ -s file,/data/vcache1/varnish_storage.bin,100G \ -s file,/data/vcache2/varnish_storage.bin,100G \ -p client_http11=on \ -p backend_http11=on \ -p thread_pool_max=4000 \ -p thread_pools=4 \ -p listen_depth=4096 \ -p lru_interval=3600 \ -p obj_workspace=4096 \ -h classic,500009" Is it by design? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 25 08:53:57 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 25 Sep 2008 08:53:57 -0000 Subject: [Varnish] #332: Varnish should greet you with a greeting Message-ID: <051.4b5beb0dc109d53864594e75191c968f@projects.linpro.no> #332: Varnish should greet you with a greeting -------------------------+-------------------------------------------------- Reporter: perbu | Owner: phk Type: enhancement | Status: new Priority: lowest | Milestone: After 2.0 Component: varnishd | Version: trunk Severity: trivial | Keywords: -------------------------+-------------------------------------------------- When you connect to the telnet interface, or when you start up varnish it would be nice if varnish could tell you its version number and svn revision. When juggling different versions whilst testing I'm often confused. If this is to intrusive it might just be a new command in the telnet/debug interface - "version". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 25 09:15:41 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 25 Sep 2008 09:15:41 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.d2c43e9ced3271cd8e8b936cacba18c7@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: reopened Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): Can you please try with beta 2? (Also, please provide varnishstat output when this happens.) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 25 10:22:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 25 Sep 2008 10:22:55 -0000 Subject: [Varnish] #191: Varnish won't cache if apache keepalive is set to on In-Reply-To: <057.afbf7964f5f8580f04cb9d3e7d90da6b@projects.linpro.no> References: <057.afbf7964f5f8580f04cb9d3e7d90da6b@projects.linpro.no> Message-ID: <066.49ba6a98a92f568d1a4841bf26d939fd@projects.linpro.no> #191: Varnish won't cache if apache keepalive is set to on -------------------------+-------------------------------------------------- Reporter: michael.lee | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 1.1.1 Severity: normal | Resolution: worksforme Keywords: keepalive | -------------------------+-------------------------------------------------- Changes (by perbu): * status: new => closed * resolution: => worksforme Comment: This works perfectly for me. If we should investigate further we need more data. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Sep 25 21:39:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 25 Sep 2008 21:39:21 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.e1931d85fb21aa49d175de2b02074e12@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: fixed in r3225 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 08:19:58 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 08:19:58 -0000 Subject: [Varnish] #333: VCL compilation commandline doesn't take account LDFLAGS Message-ID: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> #333: VCL compilation commandline doesn't take account LDFLAGS ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- In MacOSX, I build varnish with: ./configure CFLAGS='-m64 -fast' LDFLAGS='-m64 -fast' but when I run varnished: /usr/local/sbin# ./varnishd -a :80 -f /etc/vcl.conf -s file,/cache1,10M storage_file: filename: /cache1 size 10 MB. mgt_run_cc(): failed to load compiled VCL program: dlopen(./vcl.1P9zoqAU.so, 6): no suitable image found. Did find: ./vcl.1P9zoqAU.so: mach-o, but wrong architecture VCL compilation failed I modified config.h to add the LDFLAGS: /* C compiler command line for VCL code */ #define VCC_CC "exec cc -fast -m64 -dynamiclib -Wl,-undefined,dynamic_lookup -o %o %s" then re-compile, this time varnishd started ok: /usr/local/sbin# ./varnishd -a :80 -f /etc/vcl.conf -s file,/cache1,10M storage_file: filename: /cache1 size 10 MB. Using old SHMFILE -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 09:17:55 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 09:17:55 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.9b2fec7eb581304b2a828506ecbb1da0@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by kierank): * status: closed => reopened * resolution: fixed => Comment: Same error still occurs with trunk {{{ 11 TxRequest b POST 11 TxURL b /esi/header.php 11 TxProtocol b HTTP/1.1 11 TxHeader b User-Agent: Opera/9.52 (Windows NT 5.1; U; en) 11 TxHeader b Host: 192.168.248.128:81 11 TxHeader b Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 11 TxHeader b Accept-Language: en-GB,en;q=0.9 11 TxHeader b Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 11 TxHeader b Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 11 TxHeader b Referer: http://192.168.248.128:81/login.php 11 TxHeader b Cookie: PHPSESSID=snip 11 TxHeader b Cookie2: $Version=1 11 TxHeader b Content-Length: 82 11 TxHeader b Content-Type: application/x-www-form-urlencoded 11 TxHeader b X-Varnish: 1580787750 11 TxHeader b X-Forwarded-For: 192.168.248.1 11 BackendClose b default 10 VCL_call c error 10 VCL_return c deliver 10 Length c 453 10 VCL_call c deliver 10 VCL_return c deliver 10 ReqEnd c 1580787750 1221497879.988952637 1221497885.012404919 0.004133463 5.023319244 0.000133038 10 ReqEnd c 0 1221497885.012661934 1221497885.012661934 0.000257015 0.000000000 0.000000000 10 SessionClose c error }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 09:25:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 09:25:12 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.2c259a3407245e2077a1a279485fb8cb@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): There is some bit of information I'm missing here, and I can't figure out what it is. Can you send me the entire varnishlog, including the initial client request ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 10:16:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 10:16:21 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.9404543b7714e2a025d9555059b490d2@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kierank): I've had no choice but to remove a few unrelated things (like elements of our web page) from the log because at this time they are proprietary. Also, the order of the log looks a bit strange but that's how it was outputted. Many thanks for your help. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 10:51:05 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 10:51:05 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.7501cf87ec3cde82a69e7cfdc6f069a3@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I've looked over the logs, and I can reproduce the scenario but not the failure. It looks to me like the communcation with the backend on fd=11 fails during the GET attempt for the included object and therefore we go from TxHeader to BackendClose in line 148-149. The most likely explanation is that the backend closed the connection and we didn't know it. To see if this is the case, you could make the following experiment to prevent reuse of the TCP connection: Insert an explicit "Connection: close" header in the rereq in the vcl_pass{} function. If that helps, we may simply be incredibly unluck about a timing race with your backend. Poul-Henning -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 11:49:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 11:49:22 -0000 Subject: [Varnish] #334: GLIBC asprintf() incompatibility Message-ID: <049.eb670f007963f38db8298ad614a26f5c@projects.linpro.no> #334: GLIBC asprintf() incompatibility ---------------------+------------------------------------------------------ Reporter: phk | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After Varnish 2.1 Component: build | Version: trunk Severity: trivial | Keywords: ---------------------+------------------------------------------------------ GLIBC does not return a NULL pointer when something goes wrong like the FreeBSD version does. Varnish checks the returned pointer for non-NULL-ness as success criteria relying on the FreeBSD sematics. This is only relevant if you run out of malloc(3) memory, in which case you are toast anyway. But it can give rise to GCC complaints about unchecked return values from asprintf(), therefore this ticket. (NB all binaries and libs need checked, therefore component==build.) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 11:59:28 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 11:59:28 -0000 Subject: [Varnish] #333: VCL compilation commandline doesn't take account LDFLAGS In-Reply-To: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> References: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> Message-ID: <061.0e99435fa27199c1cda0e4bfcf1daf14@projects.linpro.no> #333: VCL compilation commandline doesn't take account LDFLAGS ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Thanks, fixed in r3227 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 12:08:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 12:08:49 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.7befd8ab9b1cc7b02aa3a5939f6e979e@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kierank): "Connection: close" in bereq does not improve the situation. I'm going to try a different backend. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 14:18:40 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 14:18:40 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.f3e0644c15c6193e05d42b4b2c54e183@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by phk): I think I figured it out, can you try r3232 ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 15:54:50 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 15:54:50 -0000 Subject: [Varnish] #333: VCL compilation commandline doesn't take account LDFLAGS In-Reply-To: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> References: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> Message-ID: <061.5ae52dba068587c1beb8558836258128@projects.linpro.no> #333: VCL compilation commandline doesn't take account LDFLAGS ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by 191919): * status: closed => reopened * resolution: fixed => Comment: Replying to [comment:1 tfheen]: > Thanks, fixed in r3227 Actually it doesn't fully work. Something strange: (1) reboot the machine (2) start the 64bit varnish with -s file,/data/cache,10M (3) varnish works (4) kill the master process (5) restart with -s file,/data/cache,10M (6) varnish told that it uses the old shmfile (7) port 80 cannot be connected, the telnet port works (8) kill the master process, unlink /data/cache (9) repeat (5) (10) varnish still told that it uses the old shmfile (11) port 80 cannot be connected, the telnet port works (12) if I don't reboot the machine, varnish always told me it uses the old shmfile even I specified a different file It only happened when I compile varnish with '-m64'. I ran it on Darwin 9.5.0 (Leopard 10.5.5). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 15:56:15 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 15:56:15 -0000 Subject: [Varnish] #333: VCL compilation commandline doesn't take account LDFLAGS In-Reply-To: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> References: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> Message-ID: <061.429615ee9817a077b0cc57a04bd6e2c1@projects.linpro.no> #333: VCL compilation commandline doesn't take account LDFLAGS ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by 191919): I forgot to mention that by default, the compiled binary is 32-bit, which works well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 16:20:07 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 16:20:07 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.99ac481b407fac0c2aa3c8940dde1556@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kierank): This works. Thank you very much. Most appreciated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Sep 26 16:29:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 26 Sep 2008 16:29:25 -0000 Subject: [Varnish] #320: ESI fails with POST fails In-Reply-To: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> References: <053.e3bb3840b612b116df29f04283c79986@projects.linpro.no> Message-ID: <062.baacc5ebc8a53e99e2108eb765f3df46@projects.linpro.no> #320: ESI fails with POST fails ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 28 04:11:16 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Sep 2008 04:11:16 -0000 Subject: [Varnish] #335: varnishncsa patch: log X-Forwarded-For instead of clientip if it exists Message-ID: <052.7d219b24bd4f51fd273737993dd5b317@projects.linpro.no> #335: varnishncsa patch: log X-Forwarded-For instead of clientip if it exists ---------------------------------------+------------------------------------ Reporter: 191919 | Type: defect Status: new | Priority: normal Milestone: Varnish 2.0 code complete | Component: varnishncsa Version: trunk | Severity: normal Keywords: | ---------------------------------------+------------------------------------ varnishncsa patch: log X-Forwarded-For instead of clientip if it exists -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 28 05:13:25 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Sep 2008 05:13:25 -0000 Subject: [Varnish] #336: varnishlog writes garbage to file Message-ID: <052.cd2bae9091dba2861c87b8f1bad0bc33@projects.linpro.no> #336: varnishlog writes garbage to file ------------------------+--------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishlog | Version: trunk Severity: blocker | Keywords: ------------------------+--------------------------------------------------- If I run varnishlog without parameters, it works ok: ~# varnishlog 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1222577791 1.0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1222577794 1.0 0 CLI - Rd ping 0 CLI - Wr 0 200 PONG 1222577797 1.0 But if I use it to write to a file: ~# varnishlog -w /data/logs/varnish.log The resulted file contains garbages: ^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578601 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578604 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578607 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578610 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578613 1.0^@^C^@^G^@^@Rd ping ^@^C^@^\^@^@Wr 0 200 PONG 1222578616 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578619 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578622 1 .0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578625 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578628 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578631 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578634 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578637 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578640 1.0^@^C^@^G^@^@Rd ping^@^C^@^\^@^@Wr 0 200 PONG 1222578643 1.0^@ I tried under MacOSX 32-bit and CentOS 5.2 64-bit. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 28 06:30:35 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Sep 2008 06:30:35 -0000 Subject: [Varnish] #336: varnishlog writes garbage to file In-Reply-To: <052.cd2bae9091dba2861c87b8f1bad0bc33@projects.linpro.no> References: <052.cd2bae9091dba2861c87b8f1bad0bc33@projects.linpro.no> Message-ID: <061.fa6ce6ac8b3b31a60dc7fbae08904c3d@projects.linpro.no> #336: varnishlog writes garbage to file ------------------------+--------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishlog | Version: trunk Severity: blocker | Resolution: invalid Keywords: | ------------------------+--------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => invalid Comment: This is correct behaviour, the -w option just copies the raw binary format from the shared memory to the specified file. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 28 08:46:39 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Sep 2008 08:46:39 -0000 Subject: [Varnish] #337: varnish doesn't work if compiled as 64bit in MacOSX Message-ID: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> #337: varnish doesn't work if compiled as 64bit in MacOSX ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: blocker | Keywords: ----------------------+----------------------------------------------------- (1) reboot the machine[[BR]] (2) start the 64bit varnish with -s file,/data/cache,10M[[BR]] (3) varnish works [[BR]] (4) kill the master process [[BR]] (5) restart with -s file,/data/cache,10M [[BR]] (6) varnish told that it uses the old shmfile [[BR]] (7) port 80 cannot be connected, the telnet port works[[BR]] (8) kill the master process, unlink /data/cache [[BR]] (9) repeat (5) [[BR]] (10) varnish still told that it uses the old shmfile [[BR]] (11) port 80 cannot be connected, the telnet port works [[BR]] (12) if I don't reboot the machine, varnish always told me it uses the old shmfile even I specified a different file [[BR]] [[BR]] It only happened when I compile varnish with '-m64'. I ran it on Darwin 9.5.0 (Leopard 10.5.5). [[BR]] By default, the compiled binary is 32-bit, which works well. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 28 09:05:19 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Sep 2008 09:05:19 -0000 Subject: [Varnish] #338: Enable kqueue on Darwin 9+ Message-ID: <052.84fd33817d36ce768ac317a5fd28a19e@projects.linpro.no> #338: Enable kqueue on Darwin 9+ ---------------------------------------+------------------------------------ Reporter: 191919 | Type: enhancement Status: new | Priority: normal Milestone: Varnish 2.0 code complete | Component: build Version: trunk | Severity: normal Keywords: | ---------------------------------------+------------------------------------ I don't know if kqueue implementation is sufficient for varnish. I tested running with kqueue in my notebook for several days and found no problems.[[BR]] [[BR]] The patch just enables kqueue on Darwin 9.*. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 28 09:45:47 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Sep 2008 09:45:47 -0000 Subject: [Varnish] #338: Enable kqueue on Darwin 9+ In-Reply-To: <052.84fd33817d36ce768ac317a5fd28a19e@projects.linpro.no> References: <052.84fd33817d36ce768ac317a5fd28a19e@projects.linpro.no> Message-ID: <061.1ecabcd16919e5e6d92e3533b2278922@projects.linpro.no> #338: Enable kqueue on Darwin 9+ -------------------------+-------------------------------------------------- Reporter: 191919 | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => fixed Comment: Committed, thanks! -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 28 12:16:40 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Sep 2008 12:16:40 -0000 Subject: [Varnish] #339: Repeated Assert error in cnt_recv() Message-ID: <053.cda8b79e62cebfb90b97fc376e1c20e6@projects.linpro.no> #339: Repeated Assert error in cnt_recv() ---------------------+------------------------------------------------------ Reporter: kierank | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: major Keywords: | ---------------------+------------------------------------------------------ I keep getting lots of random Assert error in cnt_recv() errors. There is no obvious link between the errors apart from when using OpenWebLoad errors seem to be very frequent. http://openwebload.sourceforge.net/ Running trunk on ubuntu server on Vmware. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Sep 28 12:57:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 28 Sep 2008 12:57:53 -0000 Subject: [Varnish] #337: varnish doesn't work if compiled as 64bit in MacOSX In-Reply-To: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> References: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> Message-ID: <061.5cb19345979449a2dff13c23de833f61@projects.linpro.no> #337: varnish doesn't work if compiled as 64bit in MacOSX ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by 191919): Sometimes even rebooting doesn't help. Start: {{{ ~# ulimit -n 65536 ~# /usr/local/sbin/varnishd -a 0.0.0.0:80 -T 0.0.0.0:6000 -f /etc/vcl.conf -s file,/data/varnish_cache,10M -p acceptor=kqueue storage_file: filename: /data/varnish_cache size 10 MB. Creating new SHMFILE }}} {{{ ~# telnet localhost 80 Trying ::1... telnet: connect to address ::1: Connection refused Trying fe80::1... telnet: connect to address fe80::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. }}} But the admin port can be connected and it works. {{{ ~# telnet localhost 6000 Trying ::1... telnet: connect to address ::1: Connection refused Trying fe80::1... telnet: connect to address fe80::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. stats 200 2725 0 Client connections accepted 0 Client requests received 0 Cache hits 0 Cache hits for pass 0 Cache misses 0 Backend connections success 0 Backend connections not attempted 0 Backend connections too many 0 Backend connections failures 0 Backend connections reuses 0 Backend connections recycles 0 Backend connections unused 0 N struct srcaddr 0 N active struct srcaddr 1 N struct sess_mem 1 N struct sess 0 N struct object 0 N struct objecthead 1 N struct smf 0 N small free smf 1 N large free smf 0 N struct vbe_conn 0 N struct bereq 10 N worker threads 10 N worker threads created 0 N worker threads not created 0 N worker threads limited 0 N queued work requests 0 N overflowed work requests 0 N dropped work requests 2 N backends 0 N expired objects 0 N LRU nuked objects 0 N LRU saved objects 0 N LRU moved objects 0 N objects on deathrow 0 HTTP header overflows 0 Objects sent with sendfile 0 Objects sent with write 0 Objects overflowing workspace 0 Total Sessions 0 Total Requests 0 Total pipe 0 Total pass 0 Total fetch 0 Total header bytes 0 Total body bytes 0 Session Closed 0 Session Pipeline 0 Session Read Ahead 0 Session Linger 0 Session herd 67 SHM records 67 SHM writes 0 SHM flushes due to overflow 0 SHM MTX contention 0 SHM cycles through buffer 0 allocator requests 0 outstanding allocations 0 bytes allocated 10485760 bytes free 0 SMA allocator requests 0 SMA outstanding allocations 0 SMA outstanding bytes 0 SMA bytes allocated 0 SMA bytes free 0 SMS allocator requests 0 SMS outstanding allocations 0 SMS outstanding bytes 0 SMS bytes allocated 0 SMS bytes freed 0 Backend requests made 1 N vcl total 1 N vcl available 0 N vcl discarded 1 N total active purges 1 N new purges added 0 N old purges deleted 0 N objects tested 0 N regexps tested against }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:13:49 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:13:49 -0000 Subject: [Varnish] #339: Repeated Assert error in cnt_recv() In-Reply-To: <053.cda8b79e62cebfb90b97fc376e1c20e6@projects.linpro.no> References: <053.cda8b79e62cebfb90b97fc376e1c20e6@projects.linpro.no> Message-ID: <062.eb2ef014d919db2f47557f44750f6d75@projects.linpro.no> #339: Repeated Assert error in cnt_recv() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * owner: => phk * component: build => varnishd Comment: If you use subroutine calls in your VCL code, please try r3236, otherwise, please forward your VCL code to us (either as attachment, or by email) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:24:09 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:24:09 -0000 Subject: [Varnish] #337: varnish doesn't work if compiled as 64bit in MacOSX In-Reply-To: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> References: <052.559645efbf0f2c1ff2d362e403fdcdf0@projects.linpro.no> Message-ID: <061.5722f4db6fd654b1b35b483ef24cbea2@projects.linpro.no> #337: varnish doesn't work if compiled as 64bit in MacOSX ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: new Priority: lowest | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * priority: normal => lowest * severity: blocker => minor * milestone: Varnish 2.0 code complete => After Varnish 2.1 Comment: Please check if the varnish child process also dies, and use your system tools to find out why port 80 is occupied. We do not have Mac OS/X development resources and will not add it to the target platforms this close to a major release, so any progress on this will have to be from your hand. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:26:17 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:26:17 -0000 Subject: [Varnish] #333: VCL compilation commandline doesn't take account LDFLAGS In-Reply-To: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> References: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> Message-ID: <061.d80119f3b851c6bf82838a847c86575c@projects.linpro.no> #333: VCL compilation commandline doesn't take account LDFLAGS ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: minor | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * priority: normal => lowest * status: reopened => closed * resolution: => duplicate * severity: normal => minor * milestone: Varnish 2.0 code complete => After Varnish 2.1 Comment: Please see #337. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:31:29 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:31:29 -0000 Subject: [Varnish] #330: 2.0-beta1 dies with accept error In-Reply-To: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> References: <053.c320e4da197530a11c303c5eccf1df84@projects.linpro.no> Message-ID: <062.ea1dcf54eff7effbfe7e709d5293eaaa@projects.linpro.no> #330: 2.0-beta1 dies with accept error ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: new Priority: low | Milestone: Varnish 2.1 release Component: varnishd | Version: trunk Severity: minor | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by wichert): FWIW: this is has now become critical for us, with varnish frequently entering an unworkable state. We are considering replacing it which squid at this point. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:37:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:37:37 -0000 Subject: [Varnish] #332: Varnish should greet you with a greeting In-Reply-To: <051.4b5beb0dc109d53864594e75191c968f@projects.linpro.no> References: <051.4b5beb0dc109d53864594e75191c968f@projects.linpro.no> Message-ID: <060.6513996b0c2910059f567c905e395f99@projects.linpro.no> #332: Varnish should greet you with a greeting -------------------------+-------------------------------------------------- Reporter: perbu | Owner: phk Type: enhancement | Status: new Priority: lowest | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: trivial | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * milestone: Varnish 2.1 release => After Varnish 2.1 Comment: This was a semi-deliberate decision and admittedly it may be wrong. The reasoning was to make it easier to write scripts, in essense allowing you to {{{ echo "url.purge $foo" | nc localhost 9090 }}} like access. Changing it at this point will break any script that actually checks the CLI return code, so I am not convinced that the convenience of changing it outweighs the number of scripts we will break. At the very least, it is a change for a major version, 3.0 in other words. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:39:56 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:39:56 -0000 Subject: [Varnish] #331: Varnish resends requests to backends after a restart In-Reply-To: <052.a26a914b192158b1ebc87683ea0f7c7c@projects.linpro.no> References: <052.a26a914b192158b1ebc87683ea0f7c7c@projects.linpro.no> Message-ID: <061.1457041120786d9738bd6a033914e2a4@projects.linpro.no> #331: Varnish resends requests to backends after a restart ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: critical | Resolution: worksforme Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: Yes, this is by design. Varnish has been designed so that restarts should rarely if ever be necessary in the first place, for instance you can change VCL program on the fly. We plan to add persistent storage to Varnish i version 2.1, but presently we do not have it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:41:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:41:37 -0000 Subject: [Varnish] #276: varnishd leaks fds and enters busy-loop In-Reply-To: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> References: <053.0a75789b433bb5c7de472fbb0e8d09a4@projects.linpro.no> Message-ID: <062.ebf400adbda9415cda7993508d0a712b@projects.linpro.no> #276: varnishd leaks fds and enters busy-loop ----------------------+----------------------------------------------------- Reporter: wichert | Owner: phk Type: defect | Status: closed Priority: high | Milestone: Varnish 2.0 code complete Component: varnishd | Version: trunk Severity: major | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Changes (by phk): * status: reopened => closed * resolution: => duplicate Comment: Duplicated in #330. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:46:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:46:22 -0000 Subject: [Varnish] #332: Varnish should greet you with a greeting In-Reply-To: <051.4b5beb0dc109d53864594e75191c968f@projects.linpro.no> References: <051.4b5beb0dc109d53864594e75191c968f@projects.linpro.no> Message-ID: <060.59bc202e30fea9adec057fb46c972a69@projects.linpro.no> #332: Varnish should greet you with a greeting -------------------------+-------------------------------------------------- Reporter: perbu | Owner: phk Type: enhancement | Status: closed Priority: lowest | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: trivial | Resolution: wontfix Keywords: | -------------------------+-------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => wontfix Comment: Moved to post-2.0 shopping-list wiki page. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 08:53:09 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 08:53:09 -0000 Subject: [Varnish] #317: Assert error in cnt_lookup(), cache_center.c line 618: In-Reply-To: <049.2001191c536f6d5ddeac8e5d28afc629@projects.linpro.no> References: <049.2001191c536f6d5ddeac8e5d28afc629@projects.linpro.no> Message-ID: <058.956c7c4987cd098b3b1d8d283d694e4a@projects.linpro.no> #317: Assert error in cnt_lookup(), cache_center.c line 618: --------------------+------------------------------------------------------- Reporter: sky | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: worksforme Keywords: | --------------------+------------------------------------------------------- Changes (by phk): * status: new => closed * resolution: => worksforme Comment: This was probably caused by the thread-pool bug (r3188 etc). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 10:49:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 10:49:37 -0000 Subject: [Varnish] #335: varnishncsa patch: log X-Forwarded-For instead of clientip if it exists In-Reply-To: <052.7d219b24bd4f51fd273737993dd5b317@projects.linpro.no> References: <052.7d219b24bd4f51fd273737993dd5b317@projects.linpro.no> Message-ID: <061.d3d0a5c74464f127a842a64f8fbf146e@projects.linpro.no> #335: varnishncsa patch: log X-Forwarded-For instead of clientip if it exists -------------------------+-------------------------------------------------- Reporter: 191919 | Owner: Type: defect | Status: closed Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishncsa | Version: trunk Severity: normal | Resolution: fixed Keywords: | -------------------------+-------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed; enable it by passing -f to varnishncsa. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 10:55:42 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 10:55:42 -0000 Subject: [Varnish] #339: Repeated Assert error in cnt_recv() In-Reply-To: <053.cda8b79e62cebfb90b97fc376e1c20e6@projects.linpro.no> References: <053.cda8b79e62cebfb90b97fc376e1c20e6@projects.linpro.no> Message-ID: <062.a09d5ae5c62048d1a63e7ed91af5c2b7@projects.linpro.no> #339: Repeated Assert error in cnt_recv() ----------------------+----------------------------------------------------- Reporter: kierank | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by kierank): This error seems to only occur on pages with ESI. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 10:56:14 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 10:56:14 -0000 Subject: [Varnish] #333: VCL compilation commandline doesn't take account LDFLAGS In-Reply-To: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> References: <052.33b924630bdaebb754f233571057c9ae@projects.linpro.no> Message-ID: <061.66591cd1d810b1ec9abd6f64d9aac827@projects.linpro.no> #333: VCL compilation commandline doesn't take account LDFLAGS ----------------------+----------------------------------------------------- Reporter: 191919 | Owner: phk Type: defect | Status: closed Priority: lowest | Milestone: After Varnish 2.1 Component: varnishd | Version: trunk Severity: minor | Resolution: duplicate Keywords: | ----------------------+----------------------------------------------------- Comment (by tfheen): You can now override the compiler command line during configure by passing VCC_CC="exec cc ..." to configure. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 21:29:21 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 21:29:21 -0000 Subject: [Varnish] #340: Silent failure on config error when starting as a daemon in CentOS5.2 Message-ID: <053.fdef91f2eeb4bff301a3a41b5007a4cf@projects.linpro.no> #340: Silent failure on config error when starting as a daemon in CentOS5.2 ---------------------+------------------------------------------------------ Reporter: marlier | Type: defect Status: new | Priority: normal Milestone: | Component: packaging Version: 2.0 | Severity: normal Keywords: beta2 | ---------------------+------------------------------------------------------ I built an RPM of varnish-2.0-beta2, and attempted to start it using a default.vcl that had worked with prior versions. It failed silently, showing simply the CentOS standard "[FAILED]" message. Upon manually tracing the steps in the startup file, I found the following error: [root at domU-12-31-38-01-C1-71:~] daemon --pidfile $pidfile $exec -P $pidfile "$DAEMON_OPTS" storage_file: filename: /var/lib/varnish/varnish_storage.bin size 1024 MB. Unknown variable 'obj.valid' At: (/etc/varnish/default.vcl Line 98 Pos 14) if (!obj.valid) { -------------#########--- VCL compilation failed [root at domU-12-31-38-01-C1-71:~] It would be very nice if this could be output in some way. I'm not sure whether the possible startup errors have distinct return codes, but if so, a switch on the retcode (which is captured) would be one possible way to do this -- even if it doesn't specify the error, it would at least make it clear that the problem was a config problem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 21:34:53 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 21:34:53 -0000 Subject: [Varnish] #341: obj.valid is not recognized as a valid variable Message-ID: <053.125b1282fcd7c04c07211c95e1c52fa6@projects.linpro.no> #341: obj.valid is not recognized as a valid variable ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- My VCL includes the following as part of the vcl_fetch definition: if (obj.status == 404) { restart; } if (!obj.valid) { error; } if (!obj.cacheable) { pass; } However, when attempting to start varnishd using this configuration, I receive the following error: Unknown variable 'obj.valid' At: (/etc/varnish/default.vcl Line 98 Pos 14) if (!obj.valid) { -------------#########--- VCL compilation failed obj.valid is still shown in the man page as a legitimate variable. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Sep 29 22:04:05 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 29 Sep 2008 22:04:05 -0000 Subject: [Varnish] #341: obj.valid is not recognized as a valid variable In-Reply-To: <053.125b1282fcd7c04c07211c95e1c52fa6@projects.linpro.no> References: <053.125b1282fcd7c04c07211c95e1c52fa6@projects.linpro.no> Message-ID: <062.949606b05edbc92de7e58a2a4166789a@projects.linpro.no> #341: obj.valid is not recognized as a valid variable ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by marlier): Never mind, I missed the note in VclSyntaxChanges -- PEBCAK :-) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 30 06:21:37 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 30 Sep 2008 06:21:37 -0000 Subject: [Varnish] #340: Silent failure on config error when starting as a daemon in CentOS5.2 In-Reply-To: <053.fdef91f2eeb4bff301a3a41b5007a4cf@projects.linpro.no> References: <053.fdef91f2eeb4bff301a3a41b5007a4cf@projects.linpro.no> Message-ID: <062.f183172aaeac1aa94f5db6e8db7f3799@projects.linpro.no> #340: Silent failure on config error when starting as a daemon in CentOS5.2 -----------------------+---------------------------------------------------- Reporter: marlier | Owner: ingvar Type: defect | Status: new Priority: normal | Milestone: Component: packaging | Version: 2.0 Severity: normal | Resolution: Keywords: beta2 | -----------------------+---------------------------------------------------- Changes (by tfheen): * owner: => ingvar -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 30 06:22:29 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 30 Sep 2008 06:22:29 -0000 Subject: [Varnish] #329: Increase cli_timeout In-Reply-To: <051.3b6b0962ee9b02647c61c97575193e77@projects.linpro.no> References: <051.3b6b0962ee9b02647c61c97575193e77@projects.linpro.no> Message-ID: <060.1feca602039239def330a61b8ac5cadd@projects.linpro.no> #329: Increase cli_timeout -------------------------+-------------------------------------------------- Reporter: perbu | Owner: perbu Type: defect | Status: new Priority: lowest | Milestone: Component: varnishd | Version: trunk Severity: trivial | Resolution: Keywords: cli_timeout | -------------------------+-------------------------------------------------- Changes (by tfheen): * owner: phk => perbu Comment: Reassigning to perbu as per IRC discussion. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 30 07:13:22 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 30 Sep 2008 07:13:22 -0000 Subject: [Varnish] #341: obj.valid is not recognized as a valid variable In-Reply-To: <053.125b1282fcd7c04c07211c95e1c52fa6@projects.linpro.no> References: <053.125b1282fcd7c04c07211c95e1c52fa6@projects.linpro.no> Message-ID: <062.b4d82650d9ced37c2e2f42bf65d2bad4@projects.linpro.no> #341: obj.valid is not recognized as a valid variable ----------------------+----------------------------------------------------- Reporter: marlier | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by tfheen): * status: new => closed * resolution: => fixed Comment: Fixed in r3241. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Sep 30 13:42:12 2008 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 30 Sep 2008 13:42:12 -0000 Subject: [Varnish] #342: error keyword in vcl_fetch fails Message-ID: <051.ca1f0eab87cc4f2beac5b0a8a72a7644@projects.linpro.no> #342: error keyword in vcl_fetch fails ----------------------+----------------------------------------------------- Reporter: wiebe | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Varnish 2.0 code complete Component: varnishd | Version: 2.0 Severity: normal | Keywords: error vcl_fetch ----------------------+----------------------------------------------------- In 2.0 beta2 the error keyword can no longer be used in the vcl_fetch routine. The request times out. -- Ticket URL: Varnish The Varnish HTTP Accelerator