From varnish-bugs at projects.linpro.no Wed Nov 1 09:09:57 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Nov 2006 09:09:57 -0000 Subject: [Varnish] #64: Overflow in varnishstat Message-ID: <077.17a08bc52f54a986fc7fef81095b4625@projects.linpro.no> #64: Overflow in varnishstat --------------------------+------------------------------------------------- Reporter: ay at linpro.no | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Keywords: overflow --------------------------+------------------------------------------------- We have a varnish (svn as of 2006-11-01). Varnishstat sometimes displays the following. 00:00:21 Hitrate ratio: 10 100 172 Hitrate avg: 0.6604 0.7549 0.7820 172 1.98 8.19 Client connections accepted 548 2.97 26.10 Client requests received 369 0.99 17.57 Cache hits 10 0.99 0.48 Cache hits for pass 168 0.99 8.00 Cache misses 179 1.98 8.52 Backend connections initiated 166 5.94 7.90 Backend connections recycles 0 0.00 0.00 Backend connections unused 56 0.00 2.67 N struct srcaddr 17 -4.95 0.81 N active struct srcaddr 39 0.00 1.86 N struct sess_mem 26 -5.94 1.24 N struct sess 175 1.98 8.33 N struct object 175 1.98 8.33 N struct objecthead 165 2.97 7.86 N struct smf 2 0.00 0.10 N small free smf 2 0.00 0.10 N large free smf 13 0.00 0.62 N struct vbe_conn 16 0.00 0.76 N worker threads 16 0.00 0.76 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 16 0.00 0.76 N overflowed work requests 0 0.00 0.00 N dropped work requests 0 0.00 0.00 N expired objects 0 0.00 0.00 N objects on deathrow 0 0.00 0.00 HTTP header overflows 152 1.98 7.24 Objects sent with sendfile 200 1.98 9.52 Objects sent with write 12961350068190840473 -5431088062805240832.00 -261209238358033856.00 Total Sessions 12961349728888425753 -5431088398748528640.00 -261209254515291712.00 Total Requests 12961349728888426744 -5431088398748527616.00 -261209254515291648.00 Total pipe 12961349728888425316 -5431088398748528640.00 -261209254515291744.00 Total pass 12961350703846000415 -5431087433443130368.00 -261209208088740544.00 Total fetch 12961349728888564487 -5431088398748525568.00 -261209254515285088.00 Total header bytes 10715740 831115.60 510273.33 Total body bytes 37 1.98 1.76 Session Closed 0 0.00 0.00 Session Pipeline 0 0.00 0.00 Session Read Ahead 501 5.94 23.86 Session herd 23144 475.25 1102.10 SHM records 1125 31.68 53.57 SHM writes 0 0.00 0.00 SHM MTX contention That looks like an integer overflow, while running the numbers seem to reset after a while, and the time-counter a the top is also reset. Runing CentOS release 4.4 on Xen 3.0 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 1 09:32:26 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Nov 2006 09:32:26 -0000 Subject: [Varnish] #64: Overflow in varnishstat In-Reply-To: <077.17a08bc52f54a986fc7fef81095b4625@projects.linpro.no> References: <077.17a08bc52f54a986fc7fef81095b4625@projects.linpro.no> Message-ID: <086.0003047cca266b3d64e6b34a2800839e@projects.linpro.no> #64: Overflow in varnishstat --------------------------+------------------------------------------------- Reporter: ay at linpro.no | Owner: phk Type: task | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: Keywords: overflow | --------------------------+------------------------------------------------- Changes (by phk): * type: defect => task Comment: This is a known issue. The situation is simply that maintaining the counters in question with proper locking would be quite expensive in terms of locking operations, and therefore they are not properly locked. If we are unlucky, the race conditions result in the loss of increments and therefore the counters will eventually go lower than zero. Doing so for an unsigned 64 bit counter gives you these incredibly large numbers. I have not decided what to do about this. It has no practical effect, but it is obviously annoying. One option is to delay the statistics and just keep track per worker thread and agrregate these once every N seconds under proper locking. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 1 12:49:20 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 01 Nov 2006 12:49:20 -0000 Subject: [Varnish] #64: Overflow in varnishstat In-Reply-To: <077.17a08bc52f54a986fc7fef81095b4625@projects.linpro.no> References: <077.17a08bc52f54a986fc7fef81095b4625@projects.linpro.no> Message-ID: <086.2de119ed8284aff91113874a1ddab943@projects.linpro.no> #64: Overflow in varnishstat --------------------------+------------------------------------------------- Reporter: ay at linpro.no | Owner: phk Type: task | Status: new Priority: normal | Milestone: Component: varnishstat | Version: trunk Severity: normal | Resolution: Keywords: overflow | --------------------------+------------------------------------------------- Comment (by ay): Well another data point to the practical effect of this is that after varnishstat keeps incrementing these incredible lagre number for about 5-15 seconds all varnish processes except the main parent process dies, and the counter is reset to 00:00:00 and all counters are reset. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Thu Nov 2 15:13:48 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Thu, 02 Nov 2006 15:13:48 -0000 Subject: [Varnish] #65: Unbuffered loggin/Logging of spawning of children. Message-ID: <077.8aee0b73c5c322c718f792fe37f8d970@projects.linpro.no> #65: Unbuffered loggin/Logging of spawning of children. -------------------------+-------------------------------------------------- Reporter: ay | Owner: des Type: enhancement | Status: new Priority: normal | Milestone: Component: build | Version: Severity: normal | Keywords: -------------------------+-------------------------------------------------- I varnish svn as of 2006-11-02 running on Centos on Xen 3.0.2 and all children dies every 2-5 minuttes. The parent process survives. Since the varnishlog is heavily buffered and does not mark a deaths and restart of childrens it's hard to figure out how and why it dies. The problem only surfaces on a productions site, so it's makes it hard to strace and try to figure out what request makes it die (if any) It would be very nice if two things could be enabled 1. Turn off buffering for logging using a switch of some kind 2. Log unexpected death (if possible) and spawning of new children, escpecially if all of them died.. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Nov 5 23:19:28 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 05 Nov 2006 23:19:28 -0000 Subject: [Varnish] #66: Varnish stops feeding pages Message-ID: <077.60eb68df7155df8bbe3418316106a646@projects.linpro.no> #66: Varnish stops feeding pages ----------------------+----------------------------------------------------- Reporter: jakobbg | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- It just stops behaving. Started in debugging mode in a screen on server as documented here: Suddenly server takes 30-60 seconds to deliver a page like . {{{ $ uname -a FreeBSD hombre.grimstveit.no 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #21: Wed Oct 4 19:03:49 CEST 2006 root at hombre.grimstveit.no:/usr/obj/usr/src/sys/HOMBRE i386 }}} {{{ $ pkg_info | grep -e apache -e php -e varnish | cut -f 1 -d ' ' apache-2.0.59 php5-5.1.6_3 php5-ctype-5.1.6_3 php5-curl-5.1.6_3 php5-dom-5.1.6_3 php5-exif-5.1.6_3 php5-extensions-1.0 php5-ftp-5.1.6_3 php5-gd-5.1.6_3 php5-gettext-5.1.6_3 php5-iconv-5.1.6_3 php5-mbstring-5.1.6_3 php5-mhash-5.1.6_3 php5-mysql-5.1.6_3 php5-pcre-5.1.6_3 php5-posix-5.1.6_3 php5-recode-5.1.6_3 php5-session-5.1.6_3 php5-simplexml-5.1.6_3 php5-sqlite-5.1.6_3 php5-tokenizer-5.1.6_3 php5-xml-5.1.6_3 php5-xmlreader-5.1.6_3 php5-xmlwriter-5.1.6_3 php5-zlib-5.1.6_3 varnish-1.0.1 }}} Some output from console: {{{ stats CLI 200 1461 2510 Client connections accepted 4639 Client requests received 1274 Cache hits 289 Cache hits for pass 2977 Cache misses 3365 Backend connections initiated 3297 Backend connections recyles 9 Backend connections unused 653 N struct srcaddr 5 N active struct srcaddr 22 N struct sess_mem 7 N struct sess 924 N struct object 924 N struct objecthead 897 N struct smf 4 N small free smf 6 N large free smf 13 N struct vbe_conn 8 N worker threads 95 N worker threads created 0 N worker threads not created 0 N worker threads limited 0 N queued work requests 95 N overflowed work requests 0 N dropped work requests 2087 N expired objects 9 N objects on deathrow 0 HTTP header overflows 1298 Objects sent with sendfile 2175 Objects sent with write 2505 Total Sessions 4633 Total Requests 30 Total pipe 484 Total pass 2845 Total fetch 1405612 Total header bytes 1032287482 Total body bytes 904 Session Closed 10 Session Pipeline 6 Session Read Ahead 3758 Session herd 276960 SHM records 23580 SHM writes 2 SHM MTX contention help CLI 200 281 Available commands: ping [timestamp] start stop stats vcl.load vcl.inline vcl.use vcl.discard vcl.list param.show [-l] [] param.set help [command] url.purge dump.pool url.purge / CLI 200 8 PURGE / Child said (2, 42624): <heap_idx != 0) not true. errno = 0 (Unknown error: 0) >> Child not responding to ping Cache child died pid=42624 status=0x86 Clean child Child cleaned start child pid 43145 Child said (2, 43145): <> Child said (2, 43145): <> url.purge CLI 104 19 Too few parameters url.purge / CLI 200 8 PURGE / }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Sun Nov 5 23:21:38 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Sun, 05 Nov 2006 23:21:38 -0000 Subject: [Varnish] #66: Varnish stops feeding pages In-Reply-To: <077.60eb68df7155df8bbe3418316106a646@projects.linpro.no> References: <077.60eb68df7155df8bbe3418316106a646@projects.linpro.no> Message-ID: <086.c9636e96282098468289c6a125a5ab2d@projects.linpro.no> #66: Varnish stops feeding pages ----------------------+----------------------------------------------------- Reporter: jakobbg | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by jakobbg): Just a quick note; my mail address is [mailto:jakob at grimstveit.no jakob at grimstveit.no] -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 6 11:08:41 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 06 Nov 2006 11:08:41 -0000 Subject: [Varnish] #67: All varnish-child-processes dies Message-ID: <077.067db0f778d30e7d6a816827c924caee@projects.linpro.no> #67: All varnish-child-processes dies ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: Severity: major | Keywords: ----------------------+----------------------------------------------------- We have a svn-varnish as of 2006-11-01 that runs infront of a resin application server in production. On full load, all varnish childprocesses dies every 2-10 minutes. The main parent respawns children and counters are reset. Since varnishlog is buffered and does not mark deaths and respawns, it's difficult to se what triggers this error. (bug #65) svn-varnish as of 2006-11-01 running on centos 4.4and xen3.0.1 32-bit 2.6.12.6-xen -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 6 13:29:11 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 06 Nov 2006 13:29:11 -0000 Subject: [Varnish] #67: All varnish-child-processes dies In-Reply-To: <077.067db0f778d30e7d6a816827c924caee@projects.linpro.no> References: <077.067db0f778d30e7d6a816827c924caee@projects.linpro.no> Message-ID: <086.db2de85630435000ae018074a099424d@projects.linpro.no> #67: All varnish-child-processes dies ----------------------+----------------------------------------------------- Reporter: ay | Owner: phk Type: defect | Status: new Priority: high | Milestone: Component: varnishd | Version: Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by ay): By setting Keepalive Off on the backends (they are loadbalanced by LVS) the the varnish children does not die as often. Instead of every 2-5 minutes is more in the range of 20 minutess. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 6 13:31:41 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 06 Nov 2006 13:31:41 -0000 Subject: [Varnish] #68: Uptime in varnishstat -1 Message-ID: <077.86e4ff0ed868c68c9fbfae8fb3e78809@projects.linpro.no> #68: Uptime in varnishstat -1 -------------------------+-------------------------------------------------- Reporter: ay | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishstat | Version: Severity: normal | Keywords: -------------------------+-------------------------------------------------- When you are running varnishstat with -1 it does not print out varnish uptime as it does with -w1. It makes it easier for tools like munin to graph uptime if uptime information is included in -1 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 7 13:38:02 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 07 Nov 2006 13:38:02 -0000 Subject: [Varnish] #65: Unbuffered loggin/Logging of spawning of children. In-Reply-To: <077.8aee0b73c5c322c718f792fe37f8d970@projects.linpro.no> References: <077.8aee0b73c5c322c718f792fe37f8d970@projects.linpro.no> Message-ID: <086.443d1a6404b9938687512a32a8b5778e@projects.linpro.no> #65: Unbuffered loggin/Logging of spawning of children. -------------------------+-------------------------------------------------- Reporter: ay | Owner: des Type: enhancement | Status: assigned Priority: normal | Milestone: Component: build | Version: Severity: normal | Resolution: Keywords: | -------------------------+-------------------------------------------------- Changes (by des): * status: new => assigned Comment: Quick-and dirty patches provided out of band. I haven't decided on a long-term solution yet. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 8 09:12:10 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Nov 2006 09:12:10 -0000 Subject: [Varnish] #69: Error in in command line parsing (-w and INF) Message-ID: <077.7aa6af0c3f4060d7d21c6f4d9a18733e@projects.linpro.no> #69: Error in in command line parsing (-w and INF) ----------------------+----------------------------------------------------- Reporter: perbu | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: major | Keywords: ----------------------+----------------------------------------------------- I run varnish like this: {{{ # /usr/sbin/varnishd -a 0.0.0.0:81 -h classic -f /var/lib/varnish/config.vcl \ -T 127.0.0.1:6082 -t 60 -w1,INF,11 -s \ file,/var/lib/varnish/varnish_storage.bin,32212254720 }}} Notice the ''-w1,INF,11''. However - when I look at "param.show" i see thread_pool_max is set to "1" which will break varnish in most production environments. Replacing INF with 10000 works around the bug for me. {{{ # telnet localhost 6082 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. param.show 200 670 default_ttl 60 [seconds] thread_pools 1 [pools] thread_pool_max 1 [threads] thread_pool_min 1 [threads] thread_pool_timeout 10 [seconds] overflow_max 100 [%] http_workspace 8192 [bytes] sess_timeout 5 [seconds] pipe_timeout 60 [seconds] send_timeout 600 [seconds] auto_restart on [bool] fetch_chunksize 128 [kilobytes] sendfile_threshold 8192 [bytes] vcl_trace off [bool] listen_address 0.0.0.0:81 listen_depth 1024 [connections] srcaddr_hash 1049 [buckets] srcaddr_ttl 30 [seconds] backend_http11 off [bool] client_http11 off [bool] }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 8 09:35:54 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Nov 2006 09:35:54 -0000 Subject: [Varnish] #69: Error in in command line parsing (-w and INF) In-Reply-To: <077.7aa6af0c3f4060d7d21c6f4d9a18733e@projects.linpro.no> References: <077.7aa6af0c3f4060d7d21c6f4d9a18733e@projects.linpro.no> Message-ID: <086.e4cbb29f150af034fc18e046e98c8fbd@projects.linpro.no> #69: Error in in command line parsing (-w and INF) ----------------------+----------------------------------------------------- Reporter: perbu | Owner: des Type: defect | Status: assigned Priority: normal | Milestone: Component: varnishd | Version: Severity: major | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: new => assigned * owner: phk => des Comment: The error is actually in the documentation, not in the code. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 8 09:36:15 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 08 Nov 2006 09:36:15 -0000 Subject: [Varnish] #69: Error in in command line parsing (-w and INF) In-Reply-To: <077.7aa6af0c3f4060d7d21c6f4d9a18733e@projects.linpro.no> References: <077.7aa6af0c3f4060d7d21c6f4d9a18733e@projects.linpro.no> Message-ID: <086.f7f49577f9996897ace5559ec9d1bd97@projects.linpro.no> #69: Error in in command line parsing (-w and INF) ----------------------+----------------------------------------------------- Reporter: perbu | Owner: des Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: Severity: major | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by des): * status: assigned => closed * resolution: => fixed Comment: Fixed in r1221. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 17 18:00:18 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Nov 2006 18:00:18 -0000 Subject: [Varnish] #70: Assert error in smf_alloc(), storage_file.c line 624 Message-ID: <077.5d707c10c4f3a8a5db4a882901663cb3@projects.linpro.no> #70: Assert error in smf_alloc(), storage_file.c line 624 ----------------------+----------------------------------------------------- Reporter: mark | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- I've been testing varnish 1.0.2 in the Wikimedia caching proxy cluster for serving/caching images. It ran relatively stable / troublefree until I gave it some more load (over 1000 req/s), after which varnishd's client process started crashing / giving assertion failures: {{{ Child said (2, 12027): < Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 17 18:04:44 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Nov 2006 18:04:44 -0000 Subject: [Varnish] #71: Missing errorhandling code in PassSession() Message-ID: <077.a4957bbf8e561e1f0af9d5640d5e1a0a@projects.linpro.no> #71: Missing errorhandling code in PassSession() ----------------------+----------------------------------------------------- Reporter: mark | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Keywords: ----------------------+----------------------------------------------------- varnish 1.0.2 varnishd just crashed once with: {{{ Child said (2, 13125): <> Cache child died pid=13125 status=0x86 }}} Default configuration, no VCL file. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 17 19:22:31 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Nov 2006 19:22:31 -0000 Subject: [Varnish] #71: Missing errorhandling code in PassSession() In-Reply-To: <077.a4957bbf8e561e1f0af9d5640d5e1a0a@projects.linpro.no> References: <077.a4957bbf8e561e1f0af9d5640d5e1a0a@projects.linpro.no> Message-ID: <086.89068c2c39871ea7ab094b25e214031d@projects.linpro.no> #71: Missing errorhandling code in PassSession() ----------------------+----------------------------------------------------- Reporter: mark | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by mark): Whoops, this seems a duplicate of #53 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Fri Nov 17 20:30:05 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Fri, 17 Nov 2006 20:30:05 -0000 Subject: [Varnish] #72: glibc detected double free or corruption Message-ID: <077.cf6ac7e33575b5ba5fdd0f2ace82ec69@projects.linpro.no> #72: glibc detected double free or corruption ----------------------+----------------------------------------------------- Reporter: mark | Owner: phk Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: 1.0 Severity: normal | Keywords: ----------------------+----------------------------------------------------- varnish 1.0.2 just crashed with the following backtrace: {{{ *** glibc detected *** /usr/local/sbin/varnishd: double free or corruption (fasttop): 0x00000000005f49b0 *** ======= Backtrace: ========= /lib/libc.so.6[0x2b1c7d247733] /lib/libc.so.6(__libc_free+0x84)[0x2b1c7d2478b4] /lib/libc.so.6(freeaddrinfo+0x28)[0x2b1c7d28e2d8] /usr/local/sbin/varnishd[0x407044] /usr/local/sbin/varnishd[0x40726a] /usr/local/sbin/varnishd[0x407396] /usr/local/sbin/varnishd[0x4077fd] /usr/local/sbin/varnishd(VBE_GetFd+0x1e)[0x407a37] /usr/local/sbin/varnishd(FetchHeaders+0x194)[0x40b848] /usr/local/sbin/varnishd[0x409198] /usr/local/sbin/varnishd(CNT_Session+0x314)[0x409aa9] /usr/local/sbin/varnishd[0x4115fb] /usr/local/sbin/varnishd[0x4119b7] /lib/libpthread.so.0[0x2b1c7d41f3ca] /lib/libc.so.6(__clone+0x6d)[0x2b1c7d2a655d] ======= Memory map: ======== 00400000-0042e000 r-xp 00000000 08:01 245218 /usr/local/sbin/varnishd 0052e000-00530000 rw-p 0002e000 08:01 245218 /usr/local/sbin/varnishd 00530000-0061f000 rw-p 00530000 00:00 0 [heap] 40000000-40001000 ---p 40000000 00:00 0 40001000-40801000 rw-p 40001000 00:00 0 40801000-40802000 ---p 40801000 00:00 0 40802000-41002000 rw-p 40802000 00:00 0 41002000-41003000 ---p 41002000 00:00 0 41003000-41803000 rw-p 41003000 00:00 0 41803000-41804000 ---p 41803000 00:00 0 41804000-42004000 rw-p 41804000 00:00 0 42004000-42005000 ---p 42004000 00:00 0 42005000-42805000 rw-p 42005000 00:00 0 42805000-42806000 ---p 42805000 00:00 0 42806000-43006000 rw-p 42806000 00:00 0 43006000-43007000 ---p 43006000 00:00 0 43007000-43807000 rw-p 43007000 00:00 0 43807000-43808000 ---p 43807000 00:00 0 43808000-44008000 rw-p 43808000 00:00 0 44008000-44009000 ---p 44008000 00:00 0 44009000-44809000 rw-p 44009000 00:00 0 44809000-4480a000 ---p 44809000 00:00 0 4480a000-4500a000 rw-p 4480a000 00:00 0 4500a000-4500b000 ---p 4500a000 00:00 0 4500b000-4580b000 rw-p 4500b000 00:00 0 4580b000-4580c000 ---p 4580b000 00:00 0 4580c000-4600c000 rw-p 4580c000 00:00 0 4600c000-4600d000 ---p 4600c000 00:00 0 4600d000-4680d000 rw-p 4600d000 00:00 0 4680d000-4680e000 ---p 4680d000 00:00 0 4680e000-4700e000 rw-p 4680e000 00:00 0 4700e000-4700f000 ---p 4700e000 00:00 0 4700f000-4780f000 rw-p 4700f000 00:00 0 4780f000-47810000 ---p 4780f000 00:00 0 47810000-48010000 rw-p 47810000 00:00 0 48010000-48011000 ---p 48010000 00:00 0 48011000-48811000 rw-p 48011000 00:00 0 48811000-48812000 ---p 48811000 00:00 0 48812000-49012000 rw-p 48812000 00:00 0 49012000-49013000 ---p 49012000 00:00 0 49013000-49813000 rw-p 49013000 00:00 0 49813000-49814000 ---p 49813000 00:00 0 49814000-4a014000 rw-p 49814000 00:00 0 4a014000-4a015000 ---p 4a014000 00:00 0 4a015000-4a815000 rw-p 4a015000 00:00 0 4a815000-4a816000 ---p 4a815000 00:00 0 4a816000-4b016000 rw-p 4a816000 00:00 0 4b016000-4b017000 ---p 4b016000 00:00 0 4b017000-4b817000 rw-p 4b017000 00:00 0 4b817000-4b818000 ---p 4b817000 00:00 0 4b818000-4c018000 rw-p 4b818000 00:00 0 4c018000-4c019000 ---p 4c018000 00:00 0 4c019000-4c819000 rw-p 4c019000 00:00 0 4c819000-4c81a000 ---p 4c819000 00:00 0 4c81a000-4d01a000 rw-p 4c81a000 00:00 0 4d01a000-4d01b000 ---p 4d01a000 00:00 0 4d01b000-4d81b000 rw-p 4d01b000 00:00 0 4d81b000-4d81c000 ---p 4d81b000 00:00 0 4d81c000-4e01c000 rw-p 4d81c000 00:00 0 4e01c000-4e01d000 ---p 4e01c000 00:00 0 4e01d000-4e81d000 rw-p 4e01d000 00:00 0 4e81d000-4e81e000 ---p 4e81d000 00:00 0 4e81e000-4f01e000 rw-p 4e81e000 00:00 0 4f01e000-4f01f000 ---p 4f01e000 00:00 0 4f01f000-4f81f000 rw-p 4f01f000 00:00 0 4f81f000-4f820000 ---p 4f81f000 00:00 0 4f820000-50020000 rw-p 4f820000 00:00 0 50020000-50021000 ---p 50020000 00:00 0 50021000-50821000 rw-p 50021000 00:00 0 50821000-50822000 ---p 50821000 00:00 0 50822000-51022000 rw-p 50822000 00:00 0 51022000-51023000 ---p 51022000 00:00 0 51023000-51823000 rw-p 51023000 00:00 0 51823000-51824000 ---p 51823000 00:00 0 51824000-52024000 rw-p 51824000 00:00 0 52024000-52025000 ---p 52024000 00:00 0 52025000-52825000 rw-p 52025000 00:00 0 52825000-52826000 ---p 52825000 00:00 0 52826000-53026000 rw-p 52826000 00:00 0 53026000-53027000 ---p 53026000 00:00 0 53027000-53827000 rw-p 53027000 00:00 0 53827000-53828000 ---p 53827000 00:00 0 53828000-54028000 rw-p 53828000 00:00 0 54028000-54029000 ---p 54028000 00:00 0 54029000-54829000 rw-p 54029000 00:00 0 54829000-5482a000 ---p 54829000 00:00 0 5482a000-5502a000 rw-p 5482a000 00:00 0 5502a000-5502b000 ---p 5502a000 00:00 0 5502b000-5582b000 rw-p 5502b000 00:00 0 5582b000-5582c000 ---p 5582b000 00:00 0 5582c000-5602c000 rw-p 5582c000 00:00 0 5602c000-5602d000 ---p 5602c000 00:00 0 5602d000-5682d000 rw-p 5602d000 00:00 0 5682d000-5682e000 ---p 5682d000 00:00 0 5682e000-5702e000 rw-p 5682e000 00:00 0 5702e000-5702f000 ---p 5702e000 00:00 0 5702f000-5782f000 rw-p 5702f000 00:00 0 5782f000-57830000 ---p 5782f000 00:00 0 57830000-58030000 rw-p 57830000 00:00 0 58030000-58031000 ---p 58030000 00:00 0 58031000-58831000 rw-p 58031000 00:00 0 58831000-58832000 ---p 58831000 00:00 0 58832000-59032000 rw-p 58832000 00:00 0 59032000-59033000 ---p 59032000 00:00 0 59033000-59833000 rw-p 59033000 00:00 0 59833000-59834000 ---p 59833000 00:00 0 59834000-5a034000 rw-p 59834000 00:00 0 5a034000-5a035000 ---p 5a034000 00:00 0 5a035000-5a835000 rw-p 5a035000 00:00 0 5a835000-5a836000 ---p 5a835000 00:00 0 5a836000-5b036000 rw-p 5a836000 00:00 0 5b036000-5b037000 ---p 5b036000 00:00 0 5b037000-5b837000 rw-p 5b037000 00:00 0 5b837000-5b838000 ---p 5b837000 00:00 0 5b838000-5c038000 rw-p 5b838000 00:00 0 5c038000-5c039000 ---p 5c038000 00:00 0 5c039000-5c839000 rw-p 5c039000 00:00 0 5c839000-5c83a000 ---p 5c839000 00:00 0 5c83a000-5d03a000 rw-p 5c83a000 00:00 0 5d03a000-5d03b000 ---p 5d03a000 00:00 0 5d03b000-5d83b000 rw-p 5d03b000 00:00 0 5d83b000-5d83c000 ---p 5d83b000 00:00 0 5d83c000-5e03c000 rw-p 5d83c000 00:00 0 5e03c000-5e03d000 ---p 5e03c000 00:00 0 5e03d000-5e83d000 rw-p 5e03d000 00:00 0 5e83d000-5e83e000 ---p 5e83d000 00:00 0 5e83e000-5f83f000 rw-p 5e83e000 00:00 0 2aaaaaaab000-2aaaaabab000 rw-p 2aaaaaaab000 00:00 0 2aaaaabab000-2aab1c514000 rw-s 00000000 08:01 179169 /tmp/varnish.JNUJ09 (deleted) 2aab1c514000-2aab1c516000 r-xp 00000000 08:01 179175 /tmp/vcl.XXjlKsev 2aab1c516000-2aab1c615000 ---p 00002000 08:01 179175 /tmp/vcl.XXjlKsev 2aab1c615000-2aab1c616000 rw-p 00001000 08:01 179175 /tmp/vcl.XXjlKsev 2aab1c700000-2aab1c76d000 rw-p 2aab1c700000 00:00 0 2aab1c76d000-2aab1c800000 ---p 2aab1c76d000 00:00 0 2aab1c800000-2aab1c826000 rw-p 2aab1c800000 00:00 0 2aab1c826000-2aab1c900000 ---p 2aab1c826000 00:00 0 2aab1c900000-2aab1c928000 rw-p 2aab1c900000 00:00 0 2aab1c928000-2aab1ca00000 ---p 2aab1c928000 00:00 0 2aab1ca00000-2aab1ca0d000 r-xp 00000000 08:01 276959 /lib/libgcc_s.so.1 2aab1ca0d000-2aab1cb0c000 ---p 0000d000 08:01 276959 /lib/libgcc_s.so.1 2aab1cb0c000-2aab1cb0d000 rw-p 0000c000 08:01 276959 /lib/libgcc_s.so.1 2aab1cc00000-2aab1cc25000 rw-p 2aab1cc00000 00:00 0 2aab1cc25000-2aab1cd00000 ---p 2aab1cc25000 00:00 0 2aab1cd00000-2aab1cd21000 rw-p 2aab1cd00000 00:00 0 2aab1cd21000-2aab1ce00000 ---p 2aab1cd21000 00:00 0 2b1c7cc95000-2b1c7ccb1000 r-xp 00000000 08:01 276909 /lib/ld-2.4.so 2b1c7ccb1000-2b1c7ccb4000 rw-p 2b1c7ccb1000 00:00 0 2b1c7cdb0000-2b1c7cdb2000 rw-p 0001b000 08:01 276909 /lib/ld-2.4.so 2b1c7cdb2000-2b1c7cdb7000 r-xp 00000000 08:01 245203 /usr/local/lib/libvarnish.so.0.0.0 2b1c7cdb7000-2b1c7ceb7000 ---p 00005000 08:01 245203 /usr/local/lib/libvarnish.so.0.0.0 2b1c7ceb7000-2b1c7ceb8000 rw-p 00005000 08:01 245203 /usr/local/lib/libvarnish.so.0.0.0 2b1c7ceb8000-2b1c7cec8000 r-xp 00000000 08:01 245213 /usr/local/lib/libvcl.so.0.0.0 2b1c7cec8000-2b1c7cfc7000 ---p 00010000 08:01 245213 /usr/local/lib/libvcl.so.0.0.0 2b1c7cfc7000-2b1c7cfc8000 rw-p 0000f000 08:01 245213 /usr/local/lib/libvcl.so.0.0.0 2b1c7cfcb000-2b1c7cfcd000 r-xp 00000000 08:01 276918 /lib/libdl-2.4.so 2b1c7cfcd000-2b1c7d0cd000 ---p 00002000 08:01 276918 /lib/libdl-2.4.so 2b1c7d0cd000-2b1c7d0cf000 rw-p 00002000 08:01 276918 /lib/libdl-2.4.so 2b1c7d0cf000-2b1c7d0d7000 r-xp 00000000 08:01 276931 /lib/librt-2.4.so 2b1c7d0d7000-2b1c7d1d6000 ---p 00008000 08:01 276931 /lib/librt-2.4.so 2b1c7d1d6000-2b1c7d1d8000 rw-p 00007000 08:01 276931 /lib/librt-2.4.so 2b1c7d1d8000-2b1c7d1d9000 rw-p 2b1c7d1d8000 00:00 0 2b1c7d1d9000-2b1c7d30f000 r-xp 00000000 08:01 276915 /lib/libc-2.4.so 2b1c7d30f000-2b1c7d40f000 ---p 00136000 08:01 276915 /lib/libc-2.4.so 2b1c7d40f000-2b1c7d412000 r--p 00136000 08:01 276915 /lib/libc-2.4.so 2b1c7d412000-2b1c7d414000 rw-p 00139000 08:01 276915 /lib/libc-2.4.so 2b1c7d414000-2b1c7d419000 rw-p 2b1c7d414000 00:00 0 2b1c7d419000-2b1c7d42a000 r-xp 00000000 08:01 276929 /lib/libpthread-2.4.so 2b1c7d42a000-2b1c7d529000 ---p 00011000 08:01 276929 /lib/libpthread-2.4.so 2b1c7d529000-2b1c7d52b000 rw-p 00010000 08:01 276929 /lib/libpthread-2.4.so 2b1c7d52b000-2b1c7d531000 rw-p 2b1c7d52b000 00:00 0 2b1c7d531000-2b1c7d53b000 r-xp 00000000 08:01 276924 /lib/libnss_files-2.4.so 2b1c7d53b000-2b1c7d63a000 ---p 0000a000 08:01 276924 /lib/libnss_files-2.4.so 2b1c7d63a000-2b1c7d63c000 rw-p 00009000 08:01 276924 /lib/libnss_files-2.4.so 2b1c7d63c000-2b1c7d640000 r-xp 00000000 08:01 276923 /lib/libnss_dns-2.4.so 2b1c7d640000-2b1c7d740000 ---p 00004000 08:01 276923 /lib/libnss_dns-2.4.so 2b1c7d740000-2b1c7d742000 rw-p 00004000 08:01 276923 /lib/libnss_dns-2.4.so 2b1c7d742000-2b1c7d753000 r-xp 00000000 08:01 276930 /lib/libresolv-2.4.so 2b1c7d753000-2b1c7d853000 ---p 00011000 08:01 276930 /lib/libresolv-2.4.so 2b1c7d853000-2b1c7d855000 rw-p 00011000 08:01 276930 /lib/libresolv-2.4.so 2b1c7d855000-2b1c7d857000 rw-p 2b1c7d855000 00:00 0 2b1c7d857000-2b1c7e058000 rw-s 00000000 08:01 179170 /tmp/_.vsl 7fff2de00000-7fff2de15000 rw-p 7fff2de00000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] 2b1c7d640000-2b1c7d740000 ---p 00004000 08:01 276923 /lib/libnss_dns-2.4.so 2b1c7d740000-2b1c7d742000 rw-p 00004000 08:01 276923 /lib/libnss_dns-2.4.so 2b1c7d742000-2b1c7d753000 r-xp 00000000 08:01 276930 /lib/libresolv-2.4.so 2b1c7d753000-2b1c7d853000 ---p 00011000 08:01 276930 /lib/libresolv-2.4.so 2b1c7d853000-2b1c7d855000 rw-p 00011000 08:01 276930 /lib/libresolv-2.4.so 2b1c7d855000-2b1c7d857000 rw-p 2b1c7d855000 00:00 0 2b1c7d857000-2b1c7e058000 rw-s 00000000 08:01 179170 /tmp/_.vsl 7fff2de00000-7fff2de15000 rw-p 7fff2de00000 00:00 0 [stack] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] Cache child died pid=15599 status=0x86 }}} Default configuration, no VCL file, malloc memory cache. Platform is Ubunty Edgy server x86_64. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Tue Nov 21 09:48:41 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Tue, 21 Nov 2006 09:48:41 -0000 Subject: [Varnish] #73: Regression test syntax Message-ID: <077.16d977ab9524f6fb3d42e4ce78ca0899@projects.linpro.no> #73: Regression test syntax --------------------+------------------------------------------------------- Reporter: phk | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: Severity: normal | Keywords: --------------------+------------------------------------------------------- Here is a mock-up for the probelem in ticket #56: {{{ # Load a suitable VCL into varnish. Other verbs: load_vcl, use_vcl match CLI syntax. test_vcl { sub vcl_recv { pass; } } # Client sends a request. Not sure about argument here. # alternative could be: client_send [-get] -proto 1.0 / client_send "GET / HTTP/1.0" # Server receives a request (default timeout) server_recv # Server sends reply. # Alternate syntax: server_send [-200] -proto 1.1 -chunked "This" "Is" "A" "Test" server_send "HTTP/1.1 200 OK" -chunked "This" "Is" "A" "Test" # Client receives reply client_recv # Check that there is no Transfer-Encoding header client_header !Transfer-Encoding # Check that the length matches what the server sent client_match length # Check that the data matches what the server sent client_match data }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 27 11:27:45 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Nov 2006 11:27:45 -0000 Subject: [Varnish] #74: varnish doesn't clean /tmp/files during runtime. Message-ID: <077.172770b9972eb5fce4ea326866136c34@projects.linpro.no> #74: varnish doesn't clean /tmp/files during runtime. --------------------+------------------------------------------------------- Reporter: bahner | Owner: des Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: Severity: normal | Keywords: --------------------+------------------------------------------------------- Bug reported by A Debian User as Debian bug [http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=400384|#400384]. When using gcc to compile a new ruleset, gcc fails to clean up its /tmp/files. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 27 11:29:37 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Nov 2006 11:29:37 -0000 Subject: [Varnish] #75: Debian-package fails to delete storage_bin on purge Message-ID: <077.f4944141ef3c7be48cb4f0252a6dbb2b@projects.linpro.no> #75: Debian-package fails to delete storage_bin on purge --------------------+------------------------------------------------------- Reporter: bahner | Owner: bahner Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: Severity: normal | Keywords: debian --------------------+------------------------------------------------------- Refer to [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400384|debian bug # 400384]. Fix is to add a specific `rm /var/lib/varnish` to postrm for --purge target. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Mon Nov 27 21:37:23 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Mon, 27 Nov 2006 21:37:23 -0000 Subject: [Varnish] #76: vcl(7) still need some work Message-ID: <077.e8a256f55ca61b8f69d469016e41e25f@projects.linpro.no> #76: vcl(7) still need some work ---------------------------+------------------------------------------------ Reporter: perbu | Owner: des Type: documentation | Status: new Priority: normal | Milestone: Varnish 1.1 Component: documentation | Version: trunk Severity: normal | Keywords: ---------------------------+------------------------------------------------ From Maxime Ritters post to varnish-misc: * What is meaning of pipe, pass, lookup, etc (you can guess for some commands, but what is the meaning of insert_pass ?)... * meaning of obj.cacheable (and obj.valid ?). Ok, it says : "this object is cacheable", but how does varnish set this variable ? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at projects.linpro.no Wed Nov 29 14:07:46 2006 From: varnish-bugs at projects.linpro.no (Varnish) Date: Wed, 29 Nov 2006 14:07:46 -0000 Subject: [Varnish] #77: URL rewrite Message-ID: <077.296f7c8ead5a70958f1e4ea93caeeee2@projects.linpro.no> #77: URL rewrite -------------------------+-------------------------------------------------- Reporter: lapo | Owner: phk Type: enhancement | Status: new Priority: normal | Milestone: Component: varnishd | Version: Severity: normal | Keywords: -------------------------+-------------------------------------------------- Complete the support for URL rewrite (AFAICT now there is a "rewrite" accepted by the tokenizer but which errors at runtime). Or maybe just let VCL write the interested vars (rewriting "Host" would be useful too). -- Ticket URL: Varnish The Varnish HTTP Accelerator