From varnish-bugs at projects.linpro.no Tue Oct 3 19:55:41 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 03 Oct 2006 19:55:41 -0000 Subject: [Varnish] #49: building fails on mac osx Message-ID: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> #49: building fails on mac osx ---------------------+------------------------------------------------------ Reporter: reinout | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 1.0 Severity: normal | Keywords: ---------------------+------------------------------------------------------ I'm trying to get it to build on my mac (osx, 10.4), but it fails halfway the Make step. Where it starts to fail: {{{ Making all in varnishd if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -include config.h -O2 -pipe -Wall -Wno-unused-parameter -Wstrict-prototypes -Wmissing- prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat -O -g -fno-inline -MT varnishd-cache_acceptor.o -MD -MP -MF ".deps/varnishd-cache_acceptor.Tpo" -c -o varnishd-cache_acceptor.o `test -f 'cache_acceptor.c' || echo './'`cache_acceptor.c; \ then mv -f ".deps/varnishd-cache_acceptor.Tpo" ".deps/varnishd- cache_acceptor.Po"; else rm -f ".deps/varnishd-cache_acceptor.Tpo"; exit 1; fi cache_acceptor.c: In function 'vca_acct': cache_acceptor.c:170: warning: implicit declaration of function 'clock_gettime' cache_acceptor.c:170: warning: nested extern declaration of 'clock_gettime' cache_acceptor.c:170: error: 'CLOCK_REALTIME' undeclared (first use in this function) cache_acceptor.c:170: error: (Each undeclared identifier is reported only once cache_acceptor.c:170: error: for each function it appears in.) {standard input}:375:non-relocatable subtraction expression, "_tv_rcvtimeo" minus "L00000000002$pb" {standard input}:375:symbol: "_tv_rcvtimeo" can't be undefined in a subtraction expression {standard input}:374:non-relocatable subtraction expression, "_tv_rcvtimeo" minus "L00000000002$pb" {standard input}:374:symbol: "_tv_rcvtimeo" can't be undefined in a subtraction expression {standard input}:366:non-relocatable subtraction expression, "_need_rcvtimeo" minus "L00000000002$pb" ...... {standard input}:100:symbol: "_need_linger" can't be undefined in a subtraction expression {standard input}:93:non-relocatable subtraction expression, "_linger" minus "L00000000001$pb" {standard input}:93:symbol: "_linger" can't be undefined in a subtraction expression {standard input}:92:non-relocatable subtraction expression, "_linger" minus "L00000000001$pb" {standard input}:92:symbol: "_linger" can't be undefined in a subtraction expression make[3]: *** [varnishd-cache_acceptor.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 }}} I ran configure with the recommended "./configure --enable-debugging- symbols --enable-developer-warnings --prefix=/opt/varnish". Any other input that's needed? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 3 23:38:12 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 03 Oct 2006 23:38:12 -0000 Subject: [Varnish] #50: Needs curses to successfull compile Message-ID: <077.dbfe3613131c304a84c6be7ead4fdc04@projects.linpro.no> #50: Needs curses to successfull compile ---------------------+------------------------------------------------------ Reporter: airmax | Owner: des Type: defect | Status: new Priority: lowest | Milestone: Component: build | Version: 1.0 Severity: trivial | Keywords: ---------------------+------------------------------------------------------ Seems like /usr/local/src/varnish-1.0.1/bin/varnishhist/varnishhist.c uses curses... but configure doesn't check existence of curses.h ! Also, adding a switch to disable varnishhist for people who don't want to install curses is a nice idea IMHO. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 4 08:49:13 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 04 Oct 2006 08:49:13 -0000 Subject: [Varnish] #49: building fails on mac osx In-Reply-To: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> References: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> Message-ID: <086.44dbcb6c5f322643bd3a3495c1c4dafe@projects.linpro.no> #49: building fails on mac osx ---------------------+------------------------------------------------------ Reporter: reinout | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: 1.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Changes (by des): * status: new => assigned Comment: This is a known issue. The solution is to * use gettimeofday() instead of clock_gettime() when the latter is not available * bug the hell out of Apple; clock_gettime() is required by POSIX. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 4 11:59:13 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 04 Oct 2006 11:59:13 -0000 Subject: [Varnish] #49: building fails on mac osx In-Reply-To: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> References: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> Message-ID: <086.4639fc6e5249d88f58ae939e20c7bdc7@projects.linpro.no> #49: building fails on mac osx ---------------------+------------------------------------------------------ Reporter: reinout | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: 1.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by batlogg): i replaced all occurances of clock_gettime with gettimeofday but it's still failing. {{{ Making all in varnishd if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -include config.h -O2 -pipe -Wall -Wno-unused-parameter -Wstrict-prototypes -Wmissing- prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wformat -O -g -fno-inline -MT varnishd-cache_acceptor.o -MD -MP -MF ".deps/varnishd-cache_acceptor.Tpo" -c -o varnishd-cache_acceptor.o `test -f 'cache_acceptor.c' || echo './'`cache_acceptor.c; \ then mv -f ".deps/varnishd-cache_acceptor.Tpo" ".deps/varnishd- cache_acceptor.Po"; else rm -f ".deps/varnishd-cache_acceptor.Tpo"; exit 1; fi cache_acceptor.c: In function ?vca_acct?: cache_acceptor.c:170: error: ?CLOCK_REALTIME? undeclared (first use in this function) cache_acceptor.c:170: error: (Each undeclared identifier is reported only once cache_acceptor.c:170: error: for each function it appears in.) cache_acceptor.c:170: warning: passing argument 2 of ?gettimeofday? from incompatible pointer type {standard input}:398:non-relocatable subtraction expression, "_tv_rcvtimeo" minus "L00000000002$pb" {standard input}:398:symbol: "_tv_rcvtimeo" can't be undefined in a subtraction expression {standard input}:394:non-relocatable subtraction expression, "_need_rcvtimeo" minus "L00000000002$pb" {standard input}:394:symbol: "_need_rcvtimeo" can't be undefined in a subtraction expression {standard input}:371:non-relocatable subtraction expression, "_tv_sndtimeo" minus "L00000000002$pb" {standard input}:371:symbol: "_tv_sndtimeo" can't be undefined in a subtraction expression {standard input}:367:non-relocatable subtraction expression, "_need_sndtimeo" minus "L00000000002$pb" {standard input}:367:symbol: "_need_sndtimeo" can't be undefined in a subtraction expression {standard input}:344:non-relocatable subtraction expression, "_linger" minus "L00000000002$pb" {standard input}:344:symbol: "_linger" can't be undefined in a subtraction expression {standard input}:340:non-relocatable subtraction expression, "_need_linger" minus "L00000000002$pb" {standard input}:340:symbol: "_need_linger" can't be undefined in a subtraction expression {standard input}:332:non-relocatable subtraction expression, "_need_test" minus "L00000000002$pb" {standard input}:332:symbol: "_need_test" can't be undefined in a subtraction expression {standard input}:237:non-relocatable subtraction expression, "_need_linger" minus "L00000000001$pb" {standard input}:237:symbol: "_need_linger" can't be undefined in a subtraction expression {standard input}:235:non-relocatable subtraction expression, "_need_sndtimeo" minus "L00000000001$pb" {standard input}:235:symbol: "_need_sndtimeo" can't be undefined in a subtraction expression {standard input}:231:non-relocatable subtraction expression, "_need_test" minus "L00000000001$pb" {standard input}:231:symbol: "_need_test" can't be undefined in a subtraction expression {standard input}:229:non-relocatable subtraction expression, "_need_rcvtimeo" minus "L00000000001$pb" {standard input}:229:symbol: "_need_rcvtimeo" can't be undefined in a subtraction expression {standard input}:226:non-relocatable subtraction expression, "_need_rcvtimeo" minus "L00000000001$pb" {standard input}:226:symbol: "_need_rcvtimeo" can't be undefined in a subtraction expression {standard input}:212:non-relocatable subtraction expression, "_tv_rcvtimeo" minus "L00000000001$pb" {standard input}:212:symbol: "_tv_rcvtimeo" can't be undefined in a subtraction expression {standard input}:168:non-relocatable subtraction expression, "_need_sndtimeo" minus "L00000000001$pb" {standard input}:168:symbol: "_need_sndtimeo" can't be undefined in a subtraction expression {standard input}:165:non-relocatable subtraction expression, "_need_sndtimeo" minus "L00000000001$pb" {standard input}:165:symbol: "_need_sndtimeo" can't be undefined in a subtraction expression {standard input}:151:non-relocatable subtraction expression, "_tv_sndtimeo" minus "L00000000001$pb" {standard input}:151:symbol: "_tv_sndtimeo" can't be undefined in a subtraction expression {standard input}:107:non-relocatable subtraction expression, "_need_linger" minus "L00000000001$pb" {standard input}:107:symbol: "_need_linger" can't be undefined in a subtraction expression {standard input}:104:non-relocatable subtraction expression, "_need_linger" minus "L00000000001$pb" {standard input}:104:symbol: "_need_linger" can't be undefined in a subtraction expression {standard input}:90:non-relocatable subtraction expression, "_linger" minus "L00000000001$pb" {standard input}:90:symbol: "_linger" can't be undefined in a subtraction expression make[3]: *** [varnishd-cache_acceptor.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Oct 4 18:51:34 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 04 Oct 2006 18:51:34 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c Message-ID: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Keywords: ----------------------+----------------------------------------------------- Hi, I'm trying varnishd, but for the moment, I'm very disappointed. Varnish doesn't run more than a minute on my setup. I tried to change the param on startup (number of worker thread, file, malloc instead of file, etc...), but the problem remains the same. varnishd crashes after some seconds, sometime just after startup, if you get lucky it may work for 60 ou 90 seconds. When I say varnishd crashes, I mean the worker process with 1 gig of shared memory crashes, the other process then forks again a new worker process, which is affected by the bug and does crash. So the reverse proxy does never really go down, but it's not very efficient this way Running with : {{{ ./varnishd -a '*:80' -b '192.168.4.230:80' -T 127.0.0.1:1664 -d -sfile,/tmp/varnish,1g -w20,200,3 }}} I got message like that : {{{ start child pid 25465 Child said (2, 25465): <> Child said (2, 25465): <> Cache child died pid=25465 status=0x6 Clean child Child cleaned }}} Test machine : Linux x86 2.6.8, 512 Mo. Backend is apache 1.3.31 on a different test machine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 5 11:13:04 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Oct 2006 11:13:04 -0000 Subject: [Varnish] #48: varnishd vanishes In-Reply-To: <077.8934eb68c89eea6fbb42e6731e3672a1@projects.linpro.no> References: <077.8934eb68c89eea6fbb42e6731e3672a1@projects.linpro.no> Message-ID: <086.b505cc7c42f2bee0c0ce3ee85ba68ba1@projects.linpro.no> #48: varnishd vanishes ----------------------+----------------------------------------------------- Reporter: perbu | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => assigned * owner: phk => des Comment: This issue is being handled out of band. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 5 11:20:27 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Oct 2006 11:20:27 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.baa7862e2ab197fd75d68045a396bb8a@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => assigned * owner: phk => des Comment: That's strange, epoll_ctl() is not supposed to return EFAULT. I'll have to dig into the kernel code to see why it does. Which kernel version are you running? In the meantime, could you please try the following: # strace -o varnish-trace.log -f varnishd -d [usual varnishd arguments] let it run a little while until the crash occurs once or twice, then kill it and submit varnish-trace.log as an attachment to this ticket. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 5 11:58:04 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Oct 2006 11:58:04 -0000 Subject: [Varnish] #45: Bodyless response to "pass"-ed request is not delivered to client until server closes connection. In-Reply-To: <077.5b399a44a1f64415b0f6084399e557cb@projects.linpro.no> References: <077.5b399a44a1f64415b0f6084399e557cb@projects.linpro.no> Message-ID: <086.b65f925ad4f3010e19cd5ccbaed26ecc@projects.linpro.no> #45: Bodyless response to "pass"-ed request is not delivered to client until server closes connection. ----------------------+----------------------------------------------------- Reporter: ilmari | Owner: phk Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => closed * resolution: => fixed Comment: Fixed, thanks. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 5 13:37:22 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Oct 2006 13:37:22 -0000 Subject: [Varnish] #52: varnishlog prints garbage Message-ID: <077.6ea22fddd787b192e6ee4923042476ae@projects.linpro.no> #52: varnishlog prints garbage ------------------------+--------------------------------------------------- Reporter: erlends | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: Severity: normal | Keywords: ------------------------+--------------------------------------------------- After a while with quite a bit of traffic, varnishlog -o returns output like this: {{{ 30578 (null) ite(read) 277 VCL_call 8306 (null) ead(read) 25888 (null) Shut write(read) 24932 (null) ) 276 VCL_call 30578 (null) ite(read) 277 VCL_call 8306 (null) ead(read) 25888 (null) Shut write(read) 24932 (null) ) 276 VCL_call 30578 (null) ite(read) 277 VCL_call 8306 (null) ead(read) 25888 (null) Shut write(read) 24932 (null) ) 276 VCL_call }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 5 14:14:53 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Oct 2006 14:14:53 -0000 Subject: [Varnish] #53: Missing errorhandling code in PassSession() Message-ID: <077.ab417f620fb8cca075c025a0ebef68bc@projects.linpro.no> #53: Missing errorhandling code in PassSession() ----------------------+----------------------------------------------------- Reporter: erlends | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Got this after "N worker threads" stopped at ~230, "N worker threads not created" started rising, and activity in the log stopped. {{{ Child said (2, 20458): <> Cache child died pid=20458 status=0x6 }}} After this message, the log and stats showed activity again until worker threads reached ~ 230 and then the same thing happened again. Running Debian Sarge, 2.6.13 kernel on a dual Xeon with 4GB mem. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Oct 5 20:24:50 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 05 Oct 2006 20:24:50 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.e7882a73992e34bebc502bc694160ceb@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by airmax): I tried strace. Got some errors messages, then it hangs, I had to kill it with a SIGKILL. Retried, same thing. I suppose that it's because strace and threads aren't friends. But I think I got our murderer : Foundry Iron load balancer and its probes. The crash occurs while varnishd is serving its probe. The iron LB check connect to port 80, and sends "HEAD http://www.diabloteen.com/ HTTP/1.1" to the server. And then, euhm, foundry knows. But I suspect them of closing the connection in an ugly way at some point . Interesting part of the strace is : {{{ 15440 read(12, "HEAD http://www.diabloteen.com/ "..., 4095) = 44 15440 clock_gettime(CLOCK_REALTIME, {1160078181, 3230000}) = 0 15440 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 15 15440 connect(15, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.4.230")}, 16) = 0 15440 getsockname(15, {sa_family=AF_INET, sin_port=htons(36177), sin_addr=inet_addr("192.168.4.46")}, [16]) = 0 15440 writev(15, [{"GET", 3}, {" ", 1}, {"http://www.diabloteen.com/", 26}, {" ", 1}, {"HTTP/1.1", 8}, {"\r\n", 2}, {"X-Varnish: 974115635", 20}, {"\r\n", 2}, {"Host: 192.168.4.230", 19}, {"\r\n", 2}, {"\r\n", 2}], 1 1) = 86 15440 read(15, "HTTP/1.1 200 OK\r\nDate: Thu, 05 O"..., 4095) = 1445 15440 time(NULL) = 1160078181 15440 open("/etc/localtime", O_RDONLY) = 16 15440 fstat64(16, {st_mode=S_IFREG|0644, st_size=1082, ...}) = 0 15440 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x83a1b000 15440 read(16, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0"..., 131072) = 1082 15440 close(16) = 0 15440 munmap(0x83a1b000, 131072) = 0 15440 fcntl64(15, F_GETFL) = 0x2 (flags O_RDWR) 15440 fcntl64(15, F_SETFL, O_RDWR) = 0 15440 close(15) = 0 15440 clock_gettime(CLOCK_REALTIME, {1160078181, 13725000}) = 0 15440 writev(12, [{"HTTP/1.1", 8}, {" ", 1}, {"200", 3}, {" ", 1}, {"OK", 2}, {"\r\n", 2}, {"Date: Thu, 05 Oct 2006 19:56:19 "..., 35}, {"\r\n", 2}, {"Server: Apache/1.3.28 (Unix) Aut"..., 62}, {"\r\n", 2}, {"pics-la bel: (pics-1.1 \"http://ww"..., 220}, {"\r\n", 2}, {"Last-Modified: Fri, 03 Mar 2006 "..., 44}, {"\r\n", 2}, {"ETag: \"26eb95d-3ac-44085a19\"", 28}, {"\r\n", 2}, {"Content-Type: text/html", 23}, {"\r\n", 2}, {"Conten t-Length: 940", 19}, {"\r\n", 2}, {"X-Varnish: 974115635", 20}, {"\r\n", 2}, {"Age: 0", 6}, {"\r\n", 2}, {"Via: 1.1 varnish", 16}, {"\r\n", 2}, {"\r\n", 2}], 27) = 512 15440 clock_gettime(CLOCK_REALTIME, {1160078181, 13924000}) = 0 15440 write(10, "\304\34\10\10", 4 15438 <... epoll_wait resumed> {{EPOLLIN, {u32=134680252, u64=134680252}}}, 1, 100) = 1 15440 <... write resumed> ) = 4 15438 read(7, "\304\34\10\10", 4) = 4 15438 epoll_ctl(11, EPOLL_CTL_ADD, 12, {EPOLLIN|EPOLLPRI, {u32=134749380, u64=134749380}}) = 0 15438 clock_gettime(CLOCK_REALTIME, {1160078181, 14120000}) = 0 15438 epoll_wait(11, 15440 read(13, 15438 <... epoll_wait resumed> {{EPOLLIN|EPOLLERR|EPOLLHUP, {u32=134749380, u64=134749380}}}, 1, 100) = 1 15438 read(12, 0x8081f44, 4095) = -1 ECONNRESET (Connection reset by peer) 15438 close(12) = 0 15438 epoll_ctl(11, EPOLL_CTL_DEL, -1, NULL) = -1 EFAULT (Bad address) 15438 write(2, "Assert error in vca_del(), cache"..., 134 15426 <... poll resumed> [{fd=0, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN, revents=POLLIN}], 3, 2225) = 1 15438 <... write resumed> ) = 134 15426 read(11, 15438 rt_sigprocmask(SIG_UNBLOCK, [ABRT], 15426 <... read resumed> "Assert error in vca_del(), cache"..., 8191) = 134 15438 <... rt_sigprocmask resumed> NULL, 8) = 0 15426 write(2, "Child said (2, 15434): < 15438 tgkill(15434, 15438, SIGABRT 15426 <... write resumed> ) = 162 15438 <... tgkill resumed> ) = 0 15426 clock_gettime(CLOCK_MONOTONIC, 15438 --- SIGABRT (Aborted) @ 0 (0) --- }}} Kernel on this test machine 2.6.8. {{{ Linux tdell4 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux }}} This kernel is a basic Debian Sarge kernel (kernel-image-2.6.8-2-686 package, version 2.6.8-16). -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 6 11:49:27 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Oct 2006 11:49:27 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.e9d020e81e11021057832680633546f4@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by des): OK, this is interesting: {{{ 15438 epoll_ctl(11, EPOLL_CTL_DEL, -1, NULL) = -1 EFAULT (Bad address) }}} the kernel should probably return {{{EBADF}}} instead of {{{EFAULT}}}, but that's beside the point; varnish should definitely not call epoll_ctl() with -1 as the third argument. I'll look into it. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 6 11:58:03 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Oct 2006 11:58:03 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.91bd1738f242682989be10c76ce7cd93@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by des): The attached patch provides a workaround. Could you please test it and report back? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 6 14:20:52 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Oct 2006 14:20:52 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.6498c6bf0acfbb615b806810a874333d@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by airmax): I tried the patch. The Foundry Load Balancer probes are now harmless, are are at least less poisoned. But, I still get a crash, at the same point. Good news (or bad news for debug), is that now I have to wait 3-4 minutes (at around 40 req/s of mostly very small files with 70% been served from cache) to get it : {{{ Child said (2, 21175): < Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 6 15:22:21 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Oct 2006 15:22:21 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.bfe7b7e45d97f4597e98eaaff60feab5@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by des): After spending far too much time reading kernel sources, I finally tracked it down. I could have saved myself some trouble by paying closer attention to the man page: {{{ BUGS In kernel versions before 2.6.9, the EPOLL_CTL_DEL operation required a non-NULL pointer in event, even though this argument is ignored. Since kernel 2.6.9, event can be specified as NULL when using EPOLL_CTL_DEL. }}} I will commit a patch for this shortly. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 6 15:50:43 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Oct 2006 15:50:43 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.1d066695c49364e9dfd41ad3fe41b09d@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by des): Can you confirm that r1143 fixes this issue? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 6 17:14:55 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 06 Oct 2006 17:14:55 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.736dd0562a92d4c9601368db12139848@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: assigned Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by airmax): Varnishd is now working on the same test machine since one hour and 10 minutes at 99 connections/seconds with no crash. So it seems to be ok. Thanks. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Oct 8 14:14:51 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 08 Oct 2006 14:14:51 -0000 Subject: [Varnish] #51: crash in cache_acceptor_epoll.c In-Reply-To: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> References: <077.6eb34e9d0529b45404ede25a7f18b956@projects.linpro.no> Message-ID: <086.954f773f32f7c8aca55a6e4ee3fc4969@projects.linpro.no> #51: crash in cache_acceptor_epoll.c ----------------------+----------------------------------------------------- Reporter: airmax | Owner: des Type: defect | Status: closed Priority: high | Milestone: Component: varnishd | Version: 1.0 Severity: blocker | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: assigned => closed * resolution: => fixed -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 9 11:29:34 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 09 Oct 2006 11:29:34 -0000 Subject: [Varnish] #53: Missing errorhandling code in PassSession() In-Reply-To: <077.ab417f620fb8cca075c025a0ebef68bc@projects.linpro.no> References: <077.ab417f620fb8cca075c025a0ebef68bc@projects.linpro.no> Message-ID: <086.37ea34ea1327acf5e71353dcbac84f34@projects.linpro.no> #53: Missing errorhandling code in PassSession() ----------------------+----------------------------------------------------- Reporter: erlends | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => assigned * owner: phk => des Comment: PassSession() needs some TLC; this is the same part of the code that is responsible for #47. I'll put it on my todo list. In the meantime, feel free to submit patches if you are so inclined. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 9 11:30:49 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 09 Oct 2006 11:30:49 -0000 Subject: [Varnish] #52: varnishlog prints garbage In-Reply-To: <077.6ea22fddd787b192e6ee4923042476ae@projects.linpro.no> References: <077.6ea22fddd787b192e6ee4923042476ae@projects.linpro.no> Message-ID: <086.faa5578776ac8e9126a645bd7ab5cd52@projects.linpro.no> #52: varnishlog prints garbage ------------------------+--------------------------------------------------- Reporter: erlends | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by des): Could you please provide additional information on your environment and the circumstances of the bug? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 9 11:30:56 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 09 Oct 2006 11:30:56 -0000 Subject: [Varnish] #52: varnishlog prints garbage In-Reply-To: <077.6ea22fddd787b192e6ee4923042476ae@projects.linpro.no> References: <077.6ea22fddd787b192e6ee4923042476ae@projects.linpro.no> Message-ID: <086.b39045fe26b9154bc2cc8b997d62dfc8@projects.linpro.no> #52: varnishlog prints garbage ------------------------+--------------------------------------------------- Reporter: erlends | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishlog | Version: Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Changes (by des): * status: new => assigned * owner: phk => des -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 9 13:52:05 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 09 Oct 2006 13:52:05 -0000 Subject: [Varnish] #52: varnishlog prints garbage In-Reply-To: <077.6ea22fddd787b192e6ee4923042476ae@projects.linpro.no> References: <077.6ea22fddd787b192e6ee4923042476ae@projects.linpro.no> Message-ID: <086.6b690bd36bdea7bd70501bf6437f813f@projects.linpro.no> #52: varnishlog prints garbage ------------------------+--------------------------------------------------- Reporter: erlends | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishlog | Version: Severity: normal | Resolution: Keywords: | ------------------------+--------------------------------------------------- Comment (by erlends): Linux, Debian Sarge. It happened after a while around the time the webserver started running out of connections and workers not started increasing. I'll try and nail it down a bit more. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 10 20:11:42 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 10 Oct 2006 20:11:42 -0000 Subject: [Varnish] #54: varnishstat gives improbable numbers Message-ID: <077.6d1719c69d63712b2f5dba48bb6a1e0a@projects.linpro.no> #54: varnishstat gives improbable numbers -------------------------+-------------------------------------------------- Reporter: bjorn | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: Severity: normal | Keywords: -------------------------+-------------------------------------------------- "N active struct srcaddr" and "N struct sess" don't look right: {{{ root at server:~# varnishstat -1 40639 Client connections accepted 40578 Client requests received 40579 Cache hits 0 Cache hits for pass 8 Cache misses 8 Backend connections initiated 8 Backend connections recycles 0 Backend connections unused 6 N struct srcaddr 18446744073709551612 N active struct srcaddr 96 N struct sess_mem 18446744073709551615 N struct sess 148 N struct object 149 N struct objecthead 2 N struct smf 0 N small free smf 1 N large free smf 1 N struct vbe_conn 85 N worker threads 148 N worker threads created 0 N worker threads not created 0 N worker threads limited 0 N queued work requests 148 N overflowed work requests 0 N dropped work requests 7 N expired objects 1 N objects on deathrow 0 HTTP header overflows 40553 Objects sent with sendfile 0 Objects sent with write 40599 Total Sessions 40587 Total Requests 0 Total pipe 0 Total pass 8 Total fetch 12705091 Total header bytes 6319233552 Total body bytes 40595 Session Closed 0 Session Pipeline 0 Session Read Ahead 0 Session herd 1182482 SHM records 163184 SHM writes 2676 SHM MTX contention }}} This varnish runs on a sparc64 system. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Oct 13 11:03:15 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 13 Oct 2006 11:03:15 -0000 Subject: [Varnish] #55: varnish stops responding with apache keepalive On Message-ID: <077.3b8ca034e359231b373596cce202dd02@projects.linpro.no> #55: varnish stops responding with apache keepalive On ----------------------+----------------------------------------------------- Reporter: ced | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: Keepalive ----------------------+----------------------------------------------------- Varnish stops responding after a few seconds when Keepalive is set on apache. Varnish launched with : /usr/local/varnish/sbin/varnishd -a '0.0.0.0:80' -b'127.0.0.1:8080' -T 127.0.0.1:1664 -sfile,/tmp/varnish,1g -t 0 uname : Linux php10 2.6.12-10-686-smp #1 SMP Fri Sep 15 16:47:57 UTC 2006 i686 GNU/Linux Trying to do a lynx -dump http://127.0.0.1:80 (to varnish) is just stuck Trying to do a lynx -dump http://127.0.0.1:8080 (to the backend) is working very fast, apache status shows almost no connection from varnish. Removing keepalive makes varnish work again (with no restart of varnishd) Here is a sample log when the problem occured : {{{ 0 ExpKill 1452272424 -1 0 ExpKill 1452272490 -1 0 ExpKill 1452272447 -1 0 ExpKill 1452272504 -1 0 ExpKill 1452272533 -1 0 ExpKill 1452272412 -1 0 ExpKill 1452272462 -1 0 ExpKill 1452272515 -1 0 ExpKill 1452272465 -1 0 ExpKill 1452272430 -1 0 WorkThread 0x6cafc1a0 end 0 ExpKill 1452272616 -1 0 ExpKill 1452272603 -1 0 ExpKill 1452272556 -1 0 ExpKill 1452272643 -1 0 ExpKill 1452272554 -1 0 ExpKill 1452360874 -48 0 ExpKill 1452360900 -30 0 ExpPick 1452272387 0 VCL_call timeout 0 VCL_return discard 0 ExpPick 1452272335 0 VCL_call timeout 0 VCL_return discard 0 ExpPick 1452272345 0 VCL_call timeout 0 VCL_return discard 0 ExpPick 1452272381 0 VCL_call timeout 0 VCL_return discard 0 ExpPick 1452272219 0 VCL_call timeout 0 VCL_return discard 0 ExpPick 1452272354 0 VCL_call timeout 0 VCL_return discard 0 ExpPick 1452272301 0 VCL_call timeout 0 VCL_return discard 0 ExpPick 1452360878 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Oct 16 17:06:44 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 16 Oct 2006 17:06:44 -0000 Subject: [Varnish] #49: building fails on mac osx In-Reply-To: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> References: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> Message-ID: <086.345b9f58b17acb5e3eff3dce4ede0836@projects.linpro.no> #49: building fails on mac osx ---------------------+------------------------------------------------------ Reporter: reinout | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: build | Version: 1.0 Severity: normal | Resolution: Keywords: | ---------------------+------------------------------------------------------ Comment (by batlogg): hi there :) any news. i'm really keen to get this running for developing zope3 integration on my machine. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 17 10:49:18 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 17 Oct 2006 10:49:18 -0000 Subject: [Varnish] #49: building fails on mac osx In-Reply-To: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> References: <077.da170d51c4818a41a1d41a5e5da910b6@projects.linpro.no> Message-ID: <086.2002acfc9559be1ebdc54c477da87039@projects.linpro.no> #49: building fails on mac osx ---------------------+------------------------------------------------------ Reporter: reinout | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 1.0 Severity: normal | Resolution: fixed Keywords: | ---------------------+------------------------------------------------------ Changes (by des): * status: assigned => closed * resolution: => fixed Comment: Fixed in trunk last week (r1145, r1146) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Oct 17 18:03:18 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 17 Oct 2006 18:03:18 -0000 Subject: [Varnish] #56: varnish respond with HTTP/1.1 when resquest was HTTP/1.0 with pass Message-ID: <077.0fbe03a2b8e275a2ef448779e7d9f4a5@projects.linpro.no> #56: varnish respond with HTTP/1.1 when resquest was HTTP/1.0 with pass ----------------------+----------------------------------------------------- Reporter: ced | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: trunk Severity: major | Keywords: ----------------------+----------------------------------------------------- How I found the bug : PHP fopen() of an URL served by varnish will fail because PHP fopen() requested HTTP/1.0 and got a HTTP/1.1 chunked transfer. Here is the log: {{{ 13 SessionOpen c 193.110.146.66 46306 13 ReqStart c 193.110.146.66 46306 867277983 13 RxRequest c GET 13 RxURL c /test.php 13 RxProtocol c HTTP/1.0 13 RxHeader c Host: xxxxx 13 VCL_call c recv 13 VCL_return c lookup 13 VCL_call c miss 13 VCL_return c fetch 16 BackendOpen b default 127.0.0.1 18904 127.0.0.1 8080 16 BackendXID b 867277983 13 Backend c 16 default 16 TxRequest b GET 16 TxURL b /test.php 16 TxProtocol b HTTP/1.1 16 TxHeader b Host: xxxxx 16 TxHeader b X-Varnish: 867277983 16 TxHeader b X-Forwarded-for: 193.110.146.66 16 RxProtocol b HTTP/1.1 16 RxStatus b 200 16 RxResponse b OK 16 RxHeader b Date: Tue, 17 Oct 2006 17:53:03 GMT 16 RxHeader b Server: Apache/1.3.34 (Unix) PHP/4.4.2 16 RxHeader b X-Powered-By: PHP/4.4.2 16 RxHeader b Connection: close 16 RxHeader b Transfer-Encoding: chunked 16 RxHeader b Content-Type: text/html; charset=iso-8859-1 13 TTL c 867277983 RFC 120 1161107583 1161107583 0 0 0 13 VCL_call c fetch 13 VCL_return c pass 13 RxProtocol c HTTP/1.1 13 RxStatus c 200 13 RxResponse c OK 13 RxHeader c Date: Tue, 17 Oct 2006 17:53:03 GMT 13 RxHeader c Server: Apache/1.3.34 (Unix) PHP/4.4.2 13 RxHeader c X-Powered-By: PHP/4.4.2 13 RxHeader c Content-Type: text/html; charset=iso-8859-1 13 RxHeader c X-Varnish: 867277983 13 RxHeader c X-Forwarded-for: 193.110.146.66 13 RxHeader c Transfer-Encoding: chunked 16 BackendClose b default 13 ReqEnd c 867277983 1161107583.126965000 1161107583.149932000 0.000098000 0.019198000 0.003769000 0 StatAddr 193.110.146.66 0 0 1 1 0 1 0 249 41315 13 SessionClose c not HTTP/1.1 13 StatSess c 193.110.146.66 46306 0 1 1 0 1 0 249 41315 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator