Child panics on OpenSolaris

Paul Wright wrighty+varnishmisc at gmail.com
Mon Feb 22 19:02:03 CET 2010


On 19 February 2010 17:45, Paul Wright <wrighty+varnishmisc at gmail.com> wrote:
> On 17 February 2010 18:46, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>> In message <282e72051002170852g532cd8acqb570e6db4b82974c at mail.gmail.com>, Paul
>> Wright writes:
>>
>>>(The cookie header ensures the request is passed through to the
>>>backend. Curl will respond with "Failure when receiving data from the
>>>peer".)
>>
>> How on earth did you get the Range header to be passed through to
>> the backend ?  It should have been filtered out...
>
> I added the following to the top of vcl_recv()
>
>        if ( req.http.Range ) {
>                unset req.http.Range;
>        }
>
> Varnish ran happily until tripping over the same bug (#649) as victori
> (on r4573).

For anyone else following along I've now had varnish running for over
5 hours without issue, here are the things I found out:

* add the Range unsetting code to ensure that such requests don't make
it through to the back end
* remove the TCP_Assert() that wraps the setsockopt() call on line 184
of bin/varnishd/cache_acceptor.c
* compile with gcc, not Sun Studio (there's still some sort of
funniness with TCP_(non)blocking() )

CC=/usr/bin/gcc CFLAGS="-O3 -L/lib/amd64 -pthreads -m64
-fomit-frame-pointer" LDFLAGS="-lumem -pthreads" ./configure
--prefix=/opt

* pass the right flags through to gcc when launching vanishd

newtask -p highfile /opt/sbin/varnishd -f /opt/etc/varnish/firebox.vcl -F \
-p 'cc_command=/usr/bin/gcc -fpic -shared -m64 -o %o %s' \
-T 127.0.0.1:9001 \
-s malloc,2G \
-p sess_timeout=5s \
-p max_restarts=12 \
-p waiter=poll \
-p connect_timeout=0s \
-p sess_workspace=65536

* keep checking http://letsgetdugg.com/2009/12/04/varnish-on-solaris/
for hints and suggestions

Many thanks to Poul-Henning Kamp and Victor Igumnov for getting us to
this point.

Cheers,

Paul.



More information about the varnish-misc mailing list