From varnish-bugs at varnish-cache.org Fri Dec 2 15:09:48 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 02 Dec 2011 15:09:48 -0000 Subject: [Varnish] #1068: Restart in vcl_deliver on a hit will cause segfault Message-ID: <044.0a2419500568f7a8d8bcd8d7f62e4521@varnish-cache.org> #1068: Restart in vcl_deliver on a hit will cause segfault --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Keywords: --------------------+------------------------------------------------------- In current trunk, doing a resetart in vcl_deliver on a hit object will cause a segfault. See attached test case. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 5 11:13:11 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 05 Dec 2011 11:13:11 -0000 Subject: [Varnish] #1067: Assert error in Tcheck() cache.h line 747 In-Reply-To: <045.8bf60881de9ff60429ade3207f21c659@varnish-cache.org> References: <045.8bf60881de9ff60429ade3207f21c659@varnish-cache.org> Message-ID: <054.cebe382c40421ad35230ad9aa5b89453@varnish-cache.org> #1067: Assert error in Tcheck() cache.h line 747 ------------------------+--------------------------------------------------- Reporter: nathanm | Type: defect Status: closed | Priority: high Milestone: | Component: build Version: 2.1.5 | Severity: major Resolution: duplicate | Keywords: ------------------------+--------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #1031, and if fixed in Varnish 3.0.2. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 6 10:20:22 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 06 Dec 2011 10:20:22 -0000 Subject: [Varnish] #1068: Restart in vcl_deliver on a hit will cause segfault In-Reply-To: <044.0a2419500568f7a8d8bcd8d7f62e4521@varnish-cache.org> References: <044.0a2419500568f7a8d8bcd8d7f62e4521@varnish-cache.org> Message-ID: <053.6d1663305a9c558f2ad0c957971c278a@varnish-cache.org> #1068: Restart in vcl_deliver on a hit will cause segfault --------------------+------------------------------------------------------- Reporter: martin | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: trunk Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [3d723fdab10f10c7f062e8350e1b81a341b28a21]) Rework the busyobj handling. This patch reworks busyobj handling so that busyobjs are owned by the issuing worker, and the worker should explicitly release it when done with it. A busy objcore only lends a pointer to it. This is to fix the current situation where the owning party is murky, and the current code will leak busyobjs in at least one situation. BusyObj's are reference counted in preperation for the streaming code. Patch also adds several asserts to help make sure the busyobjs are sound. Fixes: #1068 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 8 11:48:26 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Dec 2011 11:48:26 -0000 Subject: [Varnish] #1056: obj.* should be available in vcl_deliver In-Reply-To: <043.fdc9eba85b012a610536d23ce7035134@varnish-cache.org> References: <043.fdc9eba85b012a610536d23ce7035134@varnish-cache.org> Message-ID: <052.ef18f928cbbff7279b062628c241a30d@varnish-cache.org> #1056: obj.* should be available in vcl_deliver ----------------------+----------------------------------------------------- Reporter: scoof | Owner: scoof Type: defect | Status: new Priority: low | Milestone: Component: varnishd | Version: trunk Severity: minor | Keywords: ----------------------+----------------------------------------------------- Comment(by grahamlyons): We would like this functionality because it appears that most headers are thrown away from the response object when Varnish generates a 304. Accessing these returns nothing: {{{ resp.http.X-Header VRT_GetHdr(sp, HDR_RESP, "\011X-Header:"); }}} And accessing this stops the VCL from compiling {{{ obj.http.X-Header }}} The header is still available via this method, but we're worried that the behaviour is undefined and might cause seg faults: {{{ VRT_GetHdr(sp, HDR_OBJ, "\011X-Header:"); }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 8 12:36:09 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Dec 2011 12:36:09 -0000 Subject: [Varnish] #1057: Varnish 3.0.2-streaming stops forwarding requests In-Reply-To: <042.a16518451d4e16cc249260f7a63d144b@varnish-cache.org> References: <042.a16518451d4e16cc249260f7a63d144b@varnish-cache.org> Message-ID: <051.f9999dfc8ea4d58242ef7891b596e538@varnish-cache.org> #1057: Varnish 3.0.2-streaming stops forwarding requests -----------------------+---------------------------------------------------- Reporter: hidi | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: varnishd | Version: 3.0.2 Severity: major | Resolution: fixed Keywords: streaming | -----------------------+---------------------------------------------------- Changes (by martin): * status: new => closed * resolution: => fixed Comment: This has been fixed in the current streaming release (3.0.2-streaming.2). Off-topic questions has been answered in other emails. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 8 16:40:41 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 08 Dec 2011 16:40:41 -0000 Subject: [Varnish] #1069: `varnishd -C` does not return an appropriate return code Message-ID: <046.c09eb74cc1dfb5995c134c2376eb7e55@varnish-cache.org> #1069: `varnishd -C` does not return an appropriate return code ----------------------+----------------------------------------------------- Reporter: erikwebb | Type: defect Status: new | Priority: high Milestone: | Component: build Version: 3.0.0 | Severity: normal Keywords: | ----------------------+----------------------------------------------------- To allow for easier scripting and management of VCL changes, the `varnishd -C` check for correct syntax should return a proper return code. Regardless of the compilation outcome, zero is returned. {{{ $ varnishd -C -f /path/to/bad/file/default.vcl Message from VCC-compiler: Expected one of 'acl', 'sub', 'backend', 'director', 'probe', or 'import' Found: 'asdasd' at ('input' Line 211 Pos 2) }asdasd -###### Running VCC-compiler failed, exit 1 $ echo $? 0 }}} {{{ $ varnishd -C -f /path/to/good/file/default.vcl /* * NB: This file is machine generated, DO NOT EDIT! * * Edit and run generate.py instead */ struct sess; struct cli; typedef void vcl_init_f(struct cli *); typedef void vcl_fini_f(struct cli *); typedef int vcl_func_f(struct sess *sp); ... $ echo $? 0 }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 12 02:23:28 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Dec 2011 02:23:28 -0000 Subject: [Varnish] #545: synthetic screws national characters In-Reply-To: <042.f079c136e5318647aaa256424b358694@varnish-cache.org> References: <042.f079c136e5318647aaa256424b358694@varnish-cache.org> Message-ID: <051.54ae2c14e047d4fc1e5c3180ce603113@varnish-cache.org> #545: synthetic screws national characters ----------------------+----------------------------------------------------- Reporter: kolo | Owner: phk Type: defect | Status: reopened Priority: normal | Milestone: Component: varnishd | Version: 2.0 Severity: normal | Resolution: Keywords: | ----------------------+----------------------------------------------------- Changes (by anarcat): * status: closed => reopened * resolution: invalid => Comment: I can't find this in the FAQ, and I can't find the shopping list. The bug is still there and I do not agree this is a feature request. Unicode support seems pretty basic to me and the string should at least be passed as is, and not mangled. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 12 12:08:34 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Dec 2011 12:08:34 -0000 Subject: [Varnish] #1070: varnishlog -k requires -O Message-ID: <046.5aa0fd0a659518b6d1c4b1f4337ca280@varnish-cache.org> #1070: varnishlog -k requires -O ------------------------+--------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 3.0.2 Severity: normal | Keywords: ------------------------+--------------------------------------------------- Varnishlog -k will not work without -O, nor is this documented. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 12 12:10:41 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 12 Dec 2011 12:10:41 -0000 Subject: [Varnish] #1071: Varnishlog -m includes NOISE Message-ID: <046.9c810e03f23c7c76d4cf7a124260e531@varnish-cache.org> #1071: Varnishlog -m includes NOISE ------------------------+--------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 3.0.2 Severity: normal | Keywords: ------------------------+--------------------------------------------------- Using varnishlog -m on production servers pretty much requires -c or -b to avoid being flooded with SessStat and such. -X is simply ugly... An option is to use -something to remove all "non- request-related records". -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 13 04:30:14 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Dec 2011 04:30:14 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart Message-ID: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart -------------------+-------------------------------------------------------- Reporter: bevo | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- on rhel6 varnish does not startup automatically at boot time. the manager process is present but not the worker child. if i run "varnishlog -d" i get the following: 0 WorkThread - 0x7fddccefab60 start 0 CLI - Rd vcl.load "boot" ./vcl.pvYlibbU.so 0 CLI - Wr 106 96 dlopen(./vcl.pvYlibbU.so): ./vcl.pvYlibbU.so: cannot open shared object file: Permission denied 0 CLI - EOF on CLI connection, worker stops if i check the permission of the file: [root at serverX ~]# ls -lah /var/lib/varnish/serverX/* -rwxr-x--- 1 root root 30K Dec 13 15:26 /var/lib/varnish/serverX/vcl.pvYlibbU.so -rw-r----- 1 root root 81M Dec 13 15:26 /var/lib/varnish/serverX/_.vsm -selinux is disabled, -varnish has been tested at starting up at s99 priority with no change. -if i stop varnish the .so file gets removed -manually starting varnish (via the init script) starts up fine This seems related to another ticket that has been closed: https://www.varnish-cache.org/trac/ticket/178 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 13 16:26:17 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Dec 2011 16:26:17 -0000 Subject: [Varnish] #1073: req.hash_always_miss should imply req.hash_ignore_busy Message-ID: <046.67b8d58456e1a0db3764369f86329e68@varnish-cache.org> #1073: req.hash_always_miss should imply req.hash_ignore_busy ----------------------+----------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishd | Version: trunk Severity: normal | Keywords: ----------------------+----------------------------------------------------- Currently, req.hash_always_miss does not imply that busy objects are ignored, which means you can actually get a cache hit even though hash_always_miss is set. Workaround: {{{ vcl_recv: if (req.hash_always_miss) { set req.hash_ignore_busy = true; } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 13 16:57:31 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 13 Dec 2011 16:57:31 -0000 Subject: [Varnish] #1074: Varnishlog -m ReqEnd: does not work Message-ID: <046.0801bd86e031008944b9c9f6e5735ff1@varnish-cache.org> #1074: Varnishlog -m ReqEnd: does not work ------------------------+--------------------------------------------------- Reporter: kristian | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: varnishlog | Version: 3.0.2 Severity: normal | Keywords: ------------------------+--------------------------------------------------- I am guessing the ReqEnd tag is used to find ... the request end. It should still be possible to match it, as it does belong to the request. (Imagine finding requests that are slow...) -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 15 23:46:58 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 15 Dec 2011 23:46:58 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.05089858b4a906b5e92e8e0ad415b5db@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart -------------------+-------------------------------------------------------- Reporter: bevo | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: 3.0.1 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- Comment(by bevo): I have found the cause of this. The daemon/package creates this directory (serverX being fqdn of host): /var/lib/varnish/serverX/ It creates this directory as root:root When the manager process compiles the vcl into a .so object it places it in /var/lib/varnish/serverX/ This is fine except that it creates the object as root:root, rather than the non privileged user that is going to read it. This is not normally a problem on alot of systems as you take advantage of the default umask which allows other read access to the file. in summary: The vcl is compiled and not set with appropriate permissions without relying on the other chmod flag for read access. this file should be created with group or user access set to the unprivileged user/group -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 16 04:22:42 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 Dec 2011 04:22:42 -0000 Subject: [Varnish] #1075: Allow directors (specifically fallback director) to take other directors as backends Message-ID: <052.03c00632cfc4bac48afa647e197df40b@varnish-cache.org> #1075: Allow directors (specifically fallback director) to take other directors as backends ----------------------------+----------------------------------------------- Reporter: halcyonCorsair | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Keywords: | ----------------------------+----------------------------------------------- Hi, I'd like to be able to pass a director to another director as a backend, for example, using the fallback director to take 2 servers in a round- robin director before falling back to a 3rd servers. eg. {{{ director frontend round-robin { { .backend = web1; } { .backend = web2; } } director default fallback { { .backend = frontend; } { .backend = web3; } // will only be used if servers in 'frontend' director are unhealthy. } }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 16 10:52:38 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 16 Dec 2011 10:52:38 -0000 Subject: [Varnish] #1075: Allow directors (specifically fallback director) to take other directors as backends In-Reply-To: <052.03c00632cfc4bac48afa647e197df40b@varnish-cache.org> References: <052.03c00632cfc4bac48afa647e197df40b@varnish-cache.org> Message-ID: <061.8fdf8e57edaccca4049b0624400540b0@varnish-cache.org> #1075: Allow directors (specifically fallback director) to take other directors as backends -----------------------------+---------------------------------------------- Reporter: halcyonCorsair | Type: enhancement Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Resolution: invalid | Keywords: -----------------------------+---------------------------------------------- Changes (by scoof): * status: new => closed * resolution: => invalid Comment: Please use the wiki for feature requests. Trac is for bugs only. https://www.varnish-cache.org/trac/wiki/Future_VCL -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Sat Dec 17 06:35:36 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Sat, 17 Dec 2011 06:35:36 -0000 Subject: [Varnish] #1075: Allow directors (specifically fallback director) to take other directors as backends In-Reply-To: <052.03c00632cfc4bac48afa647e197df40b@varnish-cache.org> References: <052.03c00632cfc4bac48afa647e197df40b@varnish-cache.org> Message-ID: <061.8b8ff6f6581d9e51c9eacf1dbe649276@varnish-cache.org> #1075: Allow directors (specifically fallback director) to take other directors as backends -----------------------------+---------------------------------------------- Reporter: halcyonCorsair | Type: enhancement Status: closed | Priority: normal Milestone: | Component: build Version: 3.0.2 | Severity: normal Resolution: invalid | Keywords: -----------------------------+---------------------------------------------- Comment(by halcyonCorsair): I don't seem to be able to edit the wiki, so how an I able to add a feature request? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 11:18:34 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 11:18:34 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.57c5df62c29b756307a859d1fb17b7fe@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: new Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Keywords: --------------------+------------------------------------------------------- Changes (by martin): * owner: => martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 14:42:42 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 14:42:42 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.70e26988c394a993f894809761dbbb82@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by Martin Blix Grydeland ): * status: new => closed * resolution: => fixed Comment: (In [ee439631b413cc5505e384c233ca36930cd33a70]) Force file permissions 0755 on compiled vcl .so file to make sure it is readable by the unprivileged user. Fixes: #1072 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 20:52:32 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 20:52:32 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.74b3f21e9e49c6f815b78851f738c372@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by bevo): * status: closed => reopened * resolution: fixed => Comment: i don't think that's the appropriate fix, your still relying on 'other' permissions is there any reason the file cannot be owned by the user as specified by the -u flag?(ie 'varnish') -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 20:53:08 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 20:53:08 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.adce786b1cabc50c097a3693c2cc80ad@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment(by bevo): but thanks for the quick response though Cheers -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 22:36:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 22:36:53 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.00a86f388f07f65b373228ea1714d0d8@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment(by martin): Why is it a problem relying on other permissions? All users (also the unprivileged one) will be able to read it (0755), and it fixed the problem in my tests. Does it not fix the problem for you? If not, please elaborate. We don't want the file to be owned by the unprivileged user, as the manager process can then potentially loose access to it. Martin -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 22:43:59 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 22:43:59 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.fcbb1c9bbf9f38b788e4a27476edc7ba@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment(by bevo): I would ask the question the other way around, why do all users need access to it? any private information in the .so object is available to anyone on the system. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 22:46:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 22:46:10 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.5a2bc7e8ef391a2ed5e9fbe62b99f2f8@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: reopened Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment(by bevo): it does 'fix' the original issue i listed either way. the manager process is owned by root so its always going to have access to the file if its owned/group owned by the unprivileged user/group if your concerned about that make it owned by root and the group by the unprivileged group? -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 22:51:40 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 22:51:40 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.ca4047aba3cc3c51f463c804f596fdc6@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by martin): * status: reopened => closed * resolution: => fixed Comment: That is a policy that is better managed at the directory level, which the sysadmin is free to restrict access to (while making sure the directory is readable by the unprivileged user) in my opinion. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Mon Dec 19 22:55:33 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Mon, 19 Dec 2011 22:55:33 -0000 Subject: [Varnish] #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart In-Reply-To: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> References: <042.5848d678c4044aa801481c788e3cfa16@varnish-cache.org> Message-ID: <051.5c52cb095441e0ebbf5499fd899eb6c7@varnish-cache.org> #1072: varnish does not start on boot up of machine but starts fine by manual /etc/init.d/varnish restart --------------------+------------------------------------------------------- Reporter: bevo | Owner: martin Type: defect | Status: closed Priority: normal | Milestone: Component: build | Version: 3.0.1 Severity: normal | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Comment(by bevo): ok fair enough, thanks for the quick fix -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 22 12:28:48 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 22 Dec 2011 12:28:48 -0000 Subject: [Varnish] #1076: Unable to ban on object http status Message-ID: <041.502fa3a290b14b0e8496aad415d3f2b1@varnish-cache.org> #1076: Unable to ban on object http status -------------------+-------------------------------------------------------- Reporter: mha | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: | -------------------+-------------------------------------------------------- varnish> ban obj.status == 500 106 unknown or unsupported field "obj.status" should be available for banning... -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 27 04:38:07 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Dec 2011 04:38:07 -0000 Subject: [Varnish] #1077: "Assert error in smp_open_segs" panic with persistent storage Message-ID: <043.c165512d738b197b7405085ff64f8c95@varnish-cache.org> #1077: "Assert error in smp_open_segs" panic with persistent storage -------------------+-------------------------------------------------------- Reporter: acdha | Type: defect Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: critical Keywords: | -------------------+-------------------------------------------------------- Running on Ubuntu 10.04 using the varnish-cache.org repository, I've noticed two repeated solid crashes using large persistent cache files. The first sign of a problem will be this message: {{{ varnishd[27978]: Child (6953) Panic message: Assert error in smp_oc_getobj(), storage_persistent_silo.c line 400: Condition((const void*)(o) >= (const void*)((sg->sc)->base) && (const void*)(o) < (const void *)((sg->sc)->base + (sg->sc)->mediasize)) not true. thread = (cache-worker) ident = Linux,2.6.32-341-ec2,x86_64,-spersistent,-smalloc,-hcritbit,epoll Backtrace: 0x42f118: /usr/sbin/varnishd() [0x42f118] 0x44c525: /usr/sbin/varnishd() [0x44c525] 0x428986: /usr/sbin/varnishd(HSH_Lookup+0x3a6) [0x428986] 0x415a79: /usr/sbin/varnishd() [0x415a79] 0x419165: /usr/sbin/varnishd(CNT_Session+0x6d5) [0x419165] 0x430aa8: /usr/sbin/varnishd() [0x430aa8] 0x430f31: /usr/sbin/varnishd() [0x430f31] 0x7f4825d909ca: /lib/libpthread.so.0(+0x69ca) [0x7f4825d909ca] 0x7f4825aed70d: /lib/libc.so.6(clone+0x6d) [0x7f4825aed70d] sp = 0x7f3bc659b008 { fd = 12, id = 12, xid = 2073042236, client = 10.210.214.8 34709, step = STP_LOOKUP, handling = hash, err_code = 200, err_reason = (null), restarts = 0, esi_level = 0 flags = bodystatus = 4 ws = 0x7f3bc659b080 { id = "sess", {s,f,r,e} = {0x7f3bc659bc90,+1152,+65536,+65536}, }, }}} At this point, varnishd will appear to be running but each child will immediately fail and no requests will actually be processed: {{{ varnishd[27978]: Child cleanup complete varnishd[27978]: child (7670) Started varnishd[27978]: Pushing vcls failed: CLI communication error (hdr) varnishd[27978]: Stopping Child varnishd[27978]: Child (7670) died signal=6 varnishd[27978]: Child (7670) Panic message: Assert error in smp_open_segs(), storage_persistent.c line 239: Condition(sg1->p.offset != sg->p.offset) not true. thread = (cache-main) ident = Linux,2.6.32-341-ec2,x86_64,-spersistent,-smalloc,-hcritbit,no_waiter Backtrace: 0x42f118: /usr/sbin/varnishd() [0x42f118] 0x44a96d: /usr/sbin/varnishd() [0x44a96d] 0x44aacb: /usr/sbin/varnishd() [0x44aacb] 0x447f57: /usr/sbin/varnishd(STV_open+0x27) [0x447f57] 0x42ddfa: /usr/sbin/varnishd(child_main+0xca) [0x42ddfa] 0x4406ee: /usr/sbin/varnishd() [0x4406ee] 0x441037: /usr/sbin/varnishd() [0x441037] 0x7f4826eb56a2: /usr/lib/varnish/libvarnish.so(+0x96a2) [0x7f4826eb56a2] 0x7f4826eb5cf8: /usr/lib/varnish/libvarnish.so(vev_schedule+0x88) [0x7f4826eb5cf8] 0x4408d9: /usr/sbin/varnishd(MGT_Run+0x139) [0x4408d9] }}} (see https://gist.github.com/1515327 for more logs) This problem is persistent - I've found two ways to restore Varnish to service: increasing the persistent cache size or deleting the file so it can be recreated. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Tue Dec 27 12:25:10 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Tue, 27 Dec 2011 12:25:10 -0000 Subject: [Varnish] #1078: req.http.host and port. Message-ID: <049.3f50561f45c6702795ff3b80064038c3@varnish-cache.org> #1078: req.http.host and port. -------------------------+-------------------------------------------------- Reporter: TychoCelchu | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: | -------------------------+-------------------------------------------------- Situation: 2 instances of varnish 3.0.2 on the same server, one on the port 80 the second on the port 81. I had a problem with req.http.host in my vcl_fetch. It doesn't work like that: req.http.host ~ "(^|\.)mydomain\.com$" I have to put the port in my condition, like that: req.http.host ~ "(^|\.)mydomain\.com\:81$" if i want it to work. I don't know if it is a normal way for you but i don't think so. The target port shouldn't be a part of the http.host in my mind. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Thu Dec 29 20:00:00 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Thu, 29 Dec 2011 20:00:00 -0000 Subject: [Varnish] #1078: req.http.host and port. In-Reply-To: <049.3f50561f45c6702795ff3b80064038c3@varnish-cache.org> References: <049.3f50561f45c6702795ff3b80064038c3@varnish-cache.org> Message-ID: <058.4be7020c02a2bdceffec76b267183f64@varnish-cache.org> #1078: req.http.host and port. -------------------------+-------------------------------------------------- Reporter: TychoCelchu | Type: enhancement Status: new | Priority: normal Milestone: | Component: varnishd Version: 3.0.2 | Severity: normal Keywords: | -------------------------+-------------------------------------------------- Comment(by nav): That is normal behaviour for HTTP Host header, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23 -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 30 09:00:43 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Dec 2011 09:00:43 -0000 Subject: [Varnish] #1079: Test v00036.vtc fails with an expectation mismatch Message-ID: <049.662b35c86251148557bcc53d0cf3f635@varnish-cache.org> #1079: Test v00036.vtc fails with an expectation mismatch -------------------------+-------------------------------------------------- Reporter: andreacampi | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------------+-------------------------------------------------- {{{ ---- s2 2.3 EXPECT req.url (/) == /foo (/foo) failed }}} -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 30 09:02:06 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Dec 2011 09:02:06 -0000 Subject: [Varnish] #1079: Test v00036.vtc fails with an expectation mismatch In-Reply-To: <049.662b35c86251148557bcc53d0cf3f635@varnish-cache.org> References: <049.662b35c86251148557bcc53d0cf3f635@varnish-cache.org> Message-ID: <058.108373da5f8b350919ba0dcdb69e20d4@varnish-cache.org> #1079: Test v00036.vtc fails with an expectation mismatch -------------------------+-------------------------------------------------- Reporter: andreacampi | Type: defect Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -------------------------+-------------------------------------------------- Comment(by andreacampi): The attached log file is from an OpenSuSE buildbot slave, but I have seen the same on my laptop running OS X Lion. -- Ticket URL: Varnish The Varnish HTTP Accelerator From varnish-bugs at varnish-cache.org Fri Dec 30 21:14:53 2011 From: varnish-bugs at varnish-cache.org (Varnish) Date: Fri, 30 Dec 2011 21:14:53 -0000 Subject: [Varnish] #1080: Enable use of PCRE JIT-compiled regexes Message-ID: <047.85a59227f1e1391c94d01f12266ef4b0@varnish-cache.org> #1080: Enable use of PCRE JIT-compiled regexes -----------------------+---------------------------------------------------- Reporter: toofishes | Type: enhancement Status: new | Priority: normal Milestone: | Component: build Version: trunk | Severity: normal Keywords: | -----------------------+---------------------------------------------------- As subject. I think I got this right and it still should be backward compatible for pre-8.20 libpcre versions. Note that pcre_compile() is also used in cache_ban.c, but I did not touch that with this patch. -- Ticket URL: Varnish The Varnish HTTP Accelerator From mcsoftec at gmail.com Tue Dec 20 13:46:36 2011 From: mcsoftec at gmail.com (M C) Date: Tue, 20 Dec 2011 13:46:36 -0000 Subject: Problem in ubuntu lucid package (initscript) Message-ID: Hi, i noticed that in the ubuntu lucid package "varnish_3.0.2-1~1lucid1_amd64.deb" under http://repo.varnish-cache.org, there is a typo in the varnishncsa init-script: -- DAEMON_OPTS="-a -w ${LOGFILE} -D -P $PIDFILE}" -- (line 23, col 38) there is only the closing brace around the "PIDFILE" variable, and this causes problems with logrotate and with automation tools which look for the pidfile and cannot find it because its name on the filesystem is wrong. Maybe this error is also present in other versions/architectures. Can this be consideres a bug? Will it be fixed? Thank you verymuch for the attention. M. -------------- next part -------------- An HTML attachment was scrubbed... URL: