Re: ./configure error for sys/mount.h

2009-04-03 Thread Dag-Erling Smørgrav
Olivier Nicole o...@cs.ait.ac.th writes:
 configure: WARNING: sys/mount.h: present but cannot be compiled

Fixed, thanks.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


./configure error for sys/mount.h

2009-04-01 Thread Olivier Nicole
Hi,

./configure reports the following error:

checking sys/mount.h usability... no
checking sys/mount.h presence... yes
configure: WARNING: sys/mount.h: present but cannot be compiled
configure: WARNING: sys/mount.h: check for missing prerequisite headers?
configure: WARNING: sys/mount.h: see the Autoconf documentation
configure: WARNING: sys/mount.h: section Present But Cannot Be Compiled
configure: WARNING: sys/mount.h: proceeding with the preprocessor's result
configure: WARNING: sys/mount.h: in the future, the compiler will take 
precedence
configure: WARNING: ## - ##
configure: WARNING: ## Report this to varnish-dev@projects.linpro.no ##
configure: WARNING: ## - ##

As requested, I report. This happens on 2.0.3 and 2.0.4, I think I
tracked it down to sys/param.h missing in conftest.c.

I am not sure it has an impact on the compilation/execution of
Varnish.

Best regards,

Olivier
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Re: Bug : Assert error in exp_timer() | (graph analysis)

2008-12-16 Thread Benjamin Sonntag
Hi,

following-up of the same bug (the main issue seems to be child not
responding to ping, killing it.)

I found that there was a spike in the netstat statistics during the
crash. (in fact, the established connexion number always grow up until
varnish crashes)

At the following url, you will found the cache during 3 crashes this
week, and the netstat at the same time (thanks munin)

http://benjamin.sonntag.fr/download/cache1b-varnish_usage-week.png

http://benjamin.sonntag.fr/download/cache1b-netstat-week.png

I hope it may help finding a solution (I keep searching, I will be in
the source again at the end of the week).

Maybe a network connection freeing procedure is missing somewhere.

regards,

Benjamin Sonntag

___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Re: Bug : Assert error in exp_timer() | (same bug, different log)

2008-12-15 Thread Benjamin Sonntag
Hi all,

I just had another crash on the same varnish server with the following
log :

Needless to say that I'm quite lost ...

I hope that all this log means nothing and that the really important
issue here is not responding to ping, killing it. Maybe all the rest
is only a consequence of the killing of the child ?

As I put fairly big values for the child check timeouts and counts, I
guess it's not normal that a child stayed like that, waiting for
anything ...

Is there a way to debug it properly ?

Regards,

Benjamin Sonntag


Dec 15 19:39:46 cache1b varnishd[63966]: Child (30657) not responding to
ping, killing it.
Dec 15 19:39:46 cache1b varnishd[63966]: Child (30657) died signal=6
Dec 15 19:39:46 cache1b varnishd[63966]: Child (30657) Panic message:
Assert error in EXP_Rearm(), cache_expire.c line 242:  
Condition(oe-timer_idx != BINHEAP_NOIDX) not true.  t
hread = (cache-worker)sp = 0x7f25cc591008 {   fd = 1135, id = 1135, xid
= 714117855,   client = 192.168.131.9:33717,   step = STP_LOOKUP,  
handling = HASH,   ws = 0x7f25cc591078 {
  id = sess, {s,f,r,e} = {0x7f25cc5917b0,,+388,(nil),+8192},  
}, worker = 0x7f26168fdcb0 { }, vcl = {   srcname =
{ /etc/varnish/default.vcl, 
   Default,   }, }, }, 
Dec 15 19:39:46 cache1b varnishd[63966]: Child cleanup complete
Dec 15 19:39:46 cache1b varnishd[63966]: child (24332) Started
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Closed fds:
4 5 6 10 11 13 14
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Child starts
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said managed to
mmap 68719476736 bytes of 68719476736
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Ready
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Probe(GET
/search/C=?definition=homepage HTTP/1.1^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Host:
192.168.131.102^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Connection:
close^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said ^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said , 4, 1)
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Probe(GET
/search/C=?definition=homepage HTTP/1.1^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Host:
192.168.131.101^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Connection:
close^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said ^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said , 4, 1)
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Probe(GET
/search/C=?definition=homepage HTTP/1.1^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Host:
192.168.131.107^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said Connection:
close^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said ^M
Dec 15 19:39:46 cache1b varnishd[63966]: Child (24332) said , 4, 1)

___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Re: Bug : Assert error in exp_timer() | Child not responding to ping, killing it.

2008-12-12 Thread Per Buer
Benjamin Sonntag wrote:
 Hi all,
 
 (first of all, I'll be glad to obtain a login/pass on the trac so that I
 may create a ticket for this one if it became a real bug ;) and help
 varnish community)


Please go to http://varnish.projects.linpro.no/register and register.
Then send me the username off list.

-- 
Per Buer - Leder Infrastruktur og Drift - Redpill Linpro
Telefon: 21 54 41 21 - Mobil: 958 39 117
http://linpro.no/ | http://redpill.se/



signature.asc
Description: OpenPGP digital signature
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Re: Bug : Assert error in exp_timer() | Child not responding to ping, killing it.

2008-12-12 Thread Poul-Henning Kamp

Hi Benjamin, I'll look at it.

Just wanted to point this out in the mean time:


 if (req.url ~ ttl=) {
if (req.url ~ ttl=001) { set obj.ttl=3600s; }
if (req.url ~ ttl=002) { set obj.ttl=7200s; }
if (req.url ~ ttl=003) { set obj.ttl=10800s; }
if (req.url ~ ttl=006) { set obj.ttl=21600s; }
if (req.url ~ ttl=009) { set obj.ttl=32400s; }
if (req.url ~ ttl=012) { set obj.ttl=43200s; }
if (req.url ~ ttl=015) { set obj.ttl=54000s; }
if (req.url ~ ttl=018) { set obj.ttl=64800s; }
if (req.url ~ ttl=021) { set obj.ttl=75600s; }
if (req.url ~ ttl=024) { set obj.ttl=86400s; }
if (req.url ~ ttl=096) { set obj.ttl=345600s; }
if (req.url ~ ttl=168) { set obj.ttl=604800s; }
if (req.url ~ ttl=672) { set obj.ttl=2419200s; }

VCL supports other units of time than seconds, so for
increased readability, you could write:

set obj.ttl = 1h;
set obj.ttl = 2h;
...
set obj.ttl = 1d;
...
set obj.ttl = 1w;
set obj.ttl = 4w;

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Bug : Assert error in exp_timer() | Child not responding to ping, killing it.

2008-12-11 Thread Benjamin Sonntag
Hi all,

(first of all, I'll be glad to obtain a login/pass on the trac so that I
may create a ticket for this one if it became a real bug ;) and help
varnish community)

I guess I found a bug :) So please find below the informations I was
able to gather to start working on this issue :

We are using varnish 2.0.2 (debian package version from lenny) on this
machine (from dell) :
Linux cache1b 2.6.25-2-amd64 #1 SMP Fri Jun 27 14:47:16 UTC 2008 x86_64
GNU/Linux
- 2 physical processors (8 pipelines total) : Intel(R) Xeon(R)
CPU   X5460  @ 3.16GHz
- 8* 4GB FB-DIMM (total 32GB RAM) (yes, I like this machine ;) )

I found a previous similar error last July in the mailing list, but
didn't know how to solve it :
we put those parameters high enough (I guess) :
cli_timeout40 [seconds]
ping_interval  12 [seconds]

The main question is : how can I create a backtrace, how can I obtain a
core dump to create this backtrace ?

Thanks for your help, I will, of course, do my best to find a solution
for this issue.

Regards,

Benjamin Sonntag





Here is what Syslog said (the most important I guess) :

Dec 11 20:17:01 cache1b /USR/SBIN/CRON[30655]: (root) CMD (   cd / 
run-parts --report /etc/cron.hourly)
Dec 11 20:17:09 cache1b varnishd[63966]: Child (42470) not responding to
ping, killing it.
 Child (42470) died signal=6
 Child (42470) Panic message: Assert error in exp_timer(),
cache_expire.c line 303:   Condition(oe2-timer_when = oe-timer_when)
not true.  thread = (cache-timeout)
 Child cleanup complete
 child (30657) Started
 Child (30657) said Closed fds: 4 5 6 10 11 13 14
 Child (30657) said Child starts
 Child (30657) said managed to mmap 68719476736 bytes of 68719476736
 Child (30657) said Ready
 Child (30657) said Probe(GET /search/C=?definition=homepage HTTP/1.1^M
 Child (30657) said Host: 192.168.131.101^M
 Child (30657) said Connection: close^M
 Child (30657) said ^M
 Child (30657) said , 4, 1)
 Child (30657) said Probe(GET /search/C=?definition=homepage HTTP/1.1^M
 Child (30657) said Host: 192.168.131.102^M
 Child (30657) said Connection: close^M
 Child (30657) said ^M
 Child (30657) said , 4, 1)
 Child (30657) said Probe(GET /search/C=?definition=homepage HTTP/1.1^M
 Child (30657) said Host: 192.168.131.107^M
 Child (30657) said Connection: close^M
 Child (30657) said ^M
 Child (30657) said , 4, 1)
Dec 11 20:20:01 cache1b /USR/SBIN/CRON[31317]: (root) CMD (if [ -x
/etc/munin...



Here is the varnishlog extract (my server is quite busy, I had a hard
time finding this place, so awk|sort|uniq|grep was my friends ;) )


 1137 StatSess c 192.168.131.8 43747 0 1 1 0 0 0 233 5
0 StatAddr - 192.168.131.8 0 285468 2281231 2281230 0 0 1873552
489132873 83107957357
 1139 ReqStart c 192.168.131.7 51390 2047115919
 1139 RxRequestc GET
 1139 RxURLc /confidential/url/blablapurge=1
 1139 RxProtocol   c HTTP/1.1
 1139 RxHeader c Host: varnish:3
 1139 RxHeader c Accept: */*
 1139 VCL_call c recv
 1139 VCL_return   c lookup
 1139 VCL_call c hash
 1139 VCL_return   c hash
 1139 VCL_call c miss
 1139 VCL_return   c fetch
 1137 BackendOpen  b be1b 192.168.131.30 35113 192.168.131.101 3
 1139 Backend  c 1137 lb3 be1b
 1137 TxRequestb GET
 1137 TxURLb /confidential/url/blablapurge=1
 1137 TxProtocol   b HTTP/1.1
 1137 TxHeader b Host: varnish:3
 1137 TxHeader b Accept: */*
 1137 TxHeader b X-Varnish: 2047115919
 1137 TxHeader b X-Forwarded-For: 192.168.131.7
 1157 SessionClose c remote closed
0 WorkThread   - 0x43033cb0 start
0 CLI  - Rd vcl.load boot ./vcl.1P9zoqAU.so
0 CLI  - Wr 0 200 Loaded ./vcl.1P9zoqAU.so as boot
0 CLI  - Rd vcl.load test ./vcl.FANefPfn.so
0 WorkThread   - 0x45037cb0 start
0 Backend_health - be2b Still sick 4--X-S-RH 1 3 8 0.021917 0.021917
HTTP/1.1 200 OK
0 Backend_health - be1b Still sick 4--X-S--- 0 3 8 0.00 0.00
0 Backend_health - be3b Still sick 4--X-S--- 0 3 8 0.00 0.00
0 WorkThread   - 0x40c85cb0 start
0 CLI  - Wr 0 200 Loaded ./vcl.FANefPfn.so as test
0 CLI  - Rd vcl.use test
0 CLI  - Wr 0 200
0 CLI  - Rd start
0 Debug- Acceptor is epoll
0 CLI  - Wr 0 200
0 WorkThread   - 0x4683acb0 start
0 WorkThread   - 0x4703bcb0 start
0 WorkThread   - 0x4783ccb0 start
0 WorkThread   - 0x4803dcb0 start
   11 SessionOpen  c 192.168.131.9 49159 :3
   11 ReqStart c 192.168.131.9 49159 705356244
   11 RxRequestc GET
   11 RxURLc /confidential/url/blablattl=120
   11 RxProtocol   c HTTP/1.1
   11 RxHeader c Host: varnish:3
   11 RxHeader c Accept: */*
   11 VCL_call c recv
   11 VCL_return   c lookup
   11 VCL_call c hash
   11 VCL_return   c hash
   11 VCL_call c miss
   11 VCL_return   c fetch
   11 VCL_call c error
   11 VCL_return   c deliver
   11 Length   c 5
   11 VCL_call

Error in messages

2008-11-14 Thread Patricio A. Bruna
What means this error? 

Nov 14 15:09:47 balanceador varnishd[28858]: Child (28859) died signal=6 
Nov 14 15:09:47 balanceador varnishd[28858]: Child (28859) Panic message: 
Missing errorhandling code in cnt_lookup(), cache_center.c line 606: 
Condition((p) != 0) not true. thread = (cache-worker)sp = 0x2ab2cff98008 { fd = 
317, id = 317, xid = 1867396264, client = 200.113.161.41:63013, step = 
STP_LOOKUP, handling = HASH, ws = 0x2ab2cff98078 { overflow id = sess, 
{s,f,r,e} = {0x2ab2cff987b0,,+8164,(nil),+8192}, }, worker = 0x2ab2ce001c00 { 
}, vcl = { srcname = { /etc/varnish/default.vcl, Default, }, }, }, 


 
Patricio Bruna V. 
IT Linux Ltda. 
http://www.it-linux.cl 
Fono : (+56-2) 333 0578 - Chile 
Fono: (+54-11) 6632 2760 - Argentina 
Móvil : (+56-09) 8827 0342 
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Re: varnishd appears to die if error is called from vcl_deliver

2008-11-14 Thread Nathan Uno
This appears to be because include/vcl_returns.h (varnish 2.0.1) asserts
that deliver shouldnt' return error:

VCL_MET_MAC(deliver,DELIVER,(VCL_RET_RESTART|VCL_RET_DELIVER))

The documentation (man 7 vcl) indicates that error can be returned from
vcl_deliver():

 The vcl_deliver subroutine may terminate with one of the
following key-
 words:

 error code [reason]
 Return the specified error code to the client and
abandon the
 request.

 deliver
 Deliver the object to the client.

It looks from the revision history that the change took place between r2341
and 4 and r3047.  It appears to be a deliberate change because vcl_error()
calls vcl_deliver().  So it appears there is a documentation bug, not a code
bug.  )

What I'm really interested in doing is forcing a document into cache without
having that document delivered.  I'm attempting to do this by defining a URL
pattern to hint to varnish to fetch a document with a specific hash (i.e.
not a hash specific to the particular request).  vcl_hash() knows what to do
and is working properly.  vcl_fetch() knows what's going on and sets the
infamous magic marker to tell vcl_deliver() what's up.

I had thought that I could just then tell vcl_deliver() to generate an
error with HTTP status code of 200 and bogus content and avoid having the
actual cached document returned.  This, however, seems not to be the case.

Am I overlooking a much simpler way to accomplish my goal?

Thanks,

Nato

On Wed, Nov 12, 2008 at 10:34 PM, Nathan Uno [EMAIL PROTECTED] wrote:

 If I call error from vcl_deliver varnishd appears to die.  For example, the
 following (nonsensical) definition:

 sub vcl_deliver {
 error 503 Badness;
 }

 ... results in the following varnishlog output (which looks like a crash to
 me):

10 SessionOpen  c 172.18.26.105 47478 :8081
10 ReqStart c 172.18.26.105 47478 1731927449
10 RxRequestc GET
10 RxURLc /PRIME/mtproxy/mtdata/14/2608/5704/1024
10 RxProtocol   c HTTP/1.1
10 RxHeader c Accept-Encoding: identity
10 RxHeader c Host: 172.18.26.105:8081
10 RxHeader c Connection: close
10 RxHeader c User-agent: Python-urllib/2.4
10 VCL_call c recv
10 VCL_return   c lookup
10 VCL_call c hash
10 VCL_return   c hash
10 VCL_call c miss
10 VCL_return   c fetch
12 BackendOpen  b default 127.0.0.1 60316 127.0.0.1 8880
10 Backend  c 12 default default
12 TxRequestb GET
12 TxURLb /PRIME/mtproxy/mtdata/14/2608/5704/1024
12 TxProtocol   b HTTP/1.1
12 TxHeader b Accept-Encoding: identity
12 TxHeader b Host: 172.18.26.105:8081
12 TxHeader b User-agent: Python-urllib/2.4
12 TxHeader b X-Varnish: 1731927449
12 TxHeader b X-Forwarded-For: 172.18.26.105
 0 CLI  - Rd vcl.load boot ./vcl.1P9zoqAU.so
 0 CLI  - Wr 0 200 Loaded ./vcl.1P9zoqAU.so as boot
 0 CLI  - Rd vcl.use boot
 0 CLI  - Wr 0 200
 0 CLI  - Rd start
 0 Debug- Acceptor is epoll
 0 CLI  - Wr 0 200
 0 WorkThread   - 0x4485ec10 start
 0 WorkThread   - 0x4525fc10 start
 0 WorkThread   - 0x45c60c10 start
 0 WorkThread   - 0x46661c10 start
 0 WorkThread   - 0x47062c10 start
 0 WorkThread   - 0x47a63c10 start
 0 WorkThread   - 0x48464c10 start
 0 WorkThread   - 0x48e65c10 start
 0 WorkThread   - 0x49866c10 start
 0 WorkThread   - 0x4a267c10 start


___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Re: varnishd appears to die if error is called from vcl_deliver

2008-11-14 Thread Nathan Uno
For the record...

I also attempted to restart from vcl_deliver(), figuring I could check
req.restart in vcl_recv() and make decisions there.

Unfortunately, while the VCL_RET_RESTART behavior in vcl_fetch() is to
restart the request at vcl_recv(), the VCL_RET_RESTART behavior for
vcl_deliver() is to INCOMPL(), which involves an abort() and I'm back where
I started.

Any other ideas out there?

Thanks,

Nato


On Fri, Nov 14, 2008 at 11:46 AM, Nathan Uno [EMAIL PROTECTED] wrote:

 This appears to be because include/vcl_returns.h (varnish 2.0.1) asserts
 that deliver shouldnt' return error:

 VCL_MET_MAC(deliver,DELIVER,(VCL_RET_RESTART|VCL_RET_DELIVER))

 The documentation (man 7 vcl) indicates that error can be returned from
 vcl_deliver():

  The vcl_deliver subroutine may terminate with one of the
 following key-
  words:

  error code [reason]
  Return the specified error code to the client and
 abandon the
  request.

  deliver
  Deliver the object to the client.

 It looks from the revision history that the change took place between r2341
 and 4 and r3047.  It appears to be a deliberate change because vcl_error()
 calls vcl_deliver().  So it appears there is a documentation bug, not a code
 bug.  )

 What I'm really interested in doing is forcing a document into cache
 without having that document delivered.  I'm attempting to do this by
 defining a URL pattern to hint to varnish to fetch a document with a
 specific hash (i.e. not a hash specific to the particular request).
 vcl_hash() knows what to do and is working properly.  vcl_fetch() knows
 what's going on and sets the infamous magic marker to tell vcl_deliver()
 what's up.

 I had thought that I could just then tell vcl_deliver() to generate an
 error with HTTP status code of 200 and bogus content and avoid having the
 actual cached document returned.  This, however, seems not to be the case.

 Am I overlooking a much simpler way to accomplish my goal?

 Thanks,

 Nato


 On Wed, Nov 12, 2008 at 10:34 PM, Nathan Uno [EMAIL PROTECTED]wrote:

 If I call error from vcl_deliver varnishd appears to die.  For example,
 the following (nonsensical) definition:

 sub vcl_deliver {
 error 503 Badness;
 }

 ... results in the following varnishlog output (which looks like a crash
 to me):

10 SessionOpen  c 172.18.26.105 47478 :8081
10 ReqStart c 172.18.26.105 47478 1731927449
10 RxRequestc GET
10 RxURLc /PRIME/mtproxy/mtdata/14/2608/5704/1024
10 RxProtocol   c HTTP/1.1
10 RxHeader c Accept-Encoding: identity
10 RxHeader c Host: 172.18.26.105:8081
10 RxHeader c Connection: close
10 RxHeader c User-agent: Python-urllib/2.4
10 VCL_call c recv
10 VCL_return   c lookup
10 VCL_call c hash
10 VCL_return   c hash
10 VCL_call c miss
10 VCL_return   c fetch
12 BackendOpen  b default 127.0.0.1 60316 127.0.0.1 8880
10 Backend  c 12 default default
12 TxRequestb GET
12 TxURLb /PRIME/mtproxy/mtdata/14/2608/5704/1024
12 TxProtocol   b HTTP/1.1
12 TxHeader b Accept-Encoding: identity
12 TxHeader b Host: 172.18.26.105:8081
12 TxHeader b User-agent: Python-urllib/2.4
12 TxHeader b X-Varnish: 1731927449
12 TxHeader b X-Forwarded-For: 172.18.26.105
 0 CLI  - Rd vcl.load boot ./vcl.1P9zoqAU.so
 0 CLI  - Wr 0 200 Loaded ./vcl.1P9zoqAU.so as boot
 0 CLI  - Rd vcl.use boot
 0 CLI  - Wr 0 200
 0 CLI  - Rd start
 0 Debug- Acceptor is epoll
 0 CLI  - Wr 0 200
 0 WorkThread   - 0x4485ec10 start
 0 WorkThread   - 0x4525fc10 start
 0 WorkThread   - 0x45c60c10 start
 0 WorkThread   - 0x46661c10 start
 0 WorkThread   - 0x47062c10 start
 0 WorkThread   - 0x47a63c10 start
 0 WorkThread   - 0x48464c10 start
 0 WorkThread   - 0x48e65c10 start
 0 WorkThread   - 0x49866c10 start
 0 WorkThread   - 0x4a267c10 start



___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


varnishd appears to die if error is called from vcl_deliver

2008-11-12 Thread Nathan Uno
If I call error from vcl_deliver varnishd appears to die.  For example, the
following (nonsensical) definition:

sub vcl_deliver {
error 503 Badness;
}

... results in the following varnishlog output (which looks like a crash to
me):

   10 SessionOpen  c 172.18.26.105 47478 :8081
   10 ReqStart c 172.18.26.105 47478 1731927449
   10 RxRequestc GET
   10 RxURLc /PRIME/mtproxy/mtdata/14/2608/5704/1024
   10 RxProtocol   c HTTP/1.1
   10 RxHeader c Accept-Encoding: identity
   10 RxHeader c Host: 172.18.26.105:8081
   10 RxHeader c Connection: close
   10 RxHeader c User-agent: Python-urllib/2.4
   10 VCL_call c recv
   10 VCL_return   c lookup
   10 VCL_call c hash
   10 VCL_return   c hash
   10 VCL_call c miss
   10 VCL_return   c fetch
   12 BackendOpen  b default 127.0.0.1 60316 127.0.0.1 8880
   10 Backend  c 12 default default
   12 TxRequestb GET
   12 TxURLb /PRIME/mtproxy/mtdata/14/2608/5704/1024
   12 TxProtocol   b HTTP/1.1
   12 TxHeader b Accept-Encoding: identity
   12 TxHeader b Host: 172.18.26.105:8081
   12 TxHeader b User-agent: Python-urllib/2.4
   12 TxHeader b X-Varnish: 1731927449
   12 TxHeader b X-Forwarded-For: 172.18.26.105
0 CLI  - Rd vcl.load boot ./vcl.1P9zoqAU.so
0 CLI  - Wr 0 200 Loaded ./vcl.1P9zoqAU.so as boot
0 CLI  - Rd vcl.use boot
0 CLI  - Wr 0 200
0 CLI  - Rd start
0 Debug- Acceptor is epoll
0 CLI  - Wr 0 200
0 WorkThread   - 0x4485ec10 start
0 WorkThread   - 0x4525fc10 start
0 WorkThread   - 0x45c60c10 start
0 WorkThread   - 0x46661c10 start
0 WorkThread   - 0x47062c10 start
0 WorkThread   - 0x47a63c10 start
0 WorkThread   - 0x48464c10 start
0 WorkThread   - 0x48e65c10 start
0 WorkThread   - 0x49866c10 start
0 WorkThread   - 0x4a267c10 start
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Configure Error with 1.1.2 on OpenBSD 4.3-beta sparc64

2008-03-03 Thread Jim Razmus
As per the instructions, here ya go:

configure: WARNING: sys/mount.h: present but cannot be compiled
configure: WARNING: sys/mount.h: check for missing prerequisite headers?
configure: WARNING: sys/mount.h: see the Autoconf documentation
configure: WARNING: sys/mount.h: section Present But Cannot Be Compiled
configure: WARNING: sys/mount.h: proceeding with the preprocessor's result
configure: WARNING: sys/mount.h: in the future, the compiler will take 
precedence
configure: WARNING: ## - ##
configure: WARNING: ## Report this to varnish-dev@projects.linpro.no ##
configure: WARNING: ## - ##

HTH,
Jim
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Error

2007-09-26 Thread surendar p
Hi,
When i compile the code,i got this error
Expected positive indentation.

what is the actual error it is?

Regards
Surendar
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Re: Error

2007-09-26 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], sure
ndar p writes:


Hi,
When i compile the code,i got this error
Expected positive indentation.

what is the actual error it is?

file and line information, please ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev


Re: Error xxx Guru Meditation

2007-07-19 Thread Manuel Amador (Rudd-O)
On jue, 2007-07-19 at 17:13 +0200, Andreas Røsdal wrote:

 Ideally, when all backend servers are down, varnish should show an old 
 cached version of the requested resource if possible. It would mean that 
 backend failures wouldn't be noticed by end users. Would this be 
 possible, or planned ?

This would also be a good idea but I'd hate to see this be the
default, because it can mask *serious* HTTP backend errors, misleading
administrators into believing the site is running OK.  At least, it
should never trigger if a Pragma: no-cache header is sent by the
client, so that the ones among us using Wget/munin/nagios to monitor our
sites can actually monitor them :-).

 
   - Andreas
Manuel Amador (Rudd-O) [EMAIL PROTECTED]
The R Zone - http://rudd-o.com/
GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/

Now playing, courtesy of Amarok: Andrea - Time to pray
What good is an obscenity trial except to popularize literature?
-- Nero Wolfe, The League of Frightened Men


signature.asc
Description: This is a digitally signed message part
___
varnish-dev mailing list
varnish-dev@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev